Closed literarymachine closed 3 years ago
Hey @literarymachine, thanks! I also favour your approach. I was getting this error with your branch:
TypeError: n3.namedNode is not a function
- gatsby-node.js:36
/.../skohub/skohub-vocabs/gatsby-node.js:36:10
- Array.forEach
- gatsby-node.js:32
/.../skohub/skohub-vocabs/gatsby-node.js:32:9
- jsonld.js:632
[skohub-vocabs]/[jsonld]/lib/jsonld.js:632:37
- util.js:460 Function.fromRDF
[skohub-vocabs]/[jsonld]/lib/util.js:460:25
- gatsby-node.js:53 Object.exports.sourceNodes
/.../skohub/skohub-vocabs/gatsby-node.js:53:28
I fixed it adding this to gatsby-node.js
:
const { DataFactory } = n3
const { namedNode } = DataFactory
There was some other thing, which I think is not related this specifically, but the narrower nodes were not showing up correctly:
I fixed this adding language
in the NestedList.js
component:
// line 163...
<NestedList
items={item.narrower}
current={current}
filter={filter}
highlight={highlight}
language={language} //<-- here
/>
Please check back if this is working for you.
I was getting this error with your branch
+1, thanks @sroertgen. I was using unsuitable test data.
@dr0i Please deploy to test.
Deployed to test.
With these changes, skos:broader
statements are replaced by the corresponding skos:narrower
statements which are apparently needed to build the HTML view of a vocab. Thus, in the SkoHub version no skos:broader
statements exist anymore. Compare:
https://github.com/acka47/nwbib-spatial/blob/master/nwbib-spatial.ttl vs. https://test.skohub.io/acka47/nwbib-spatial/heads/master/nwbib.de/spatial.json
I think this can be confusing to people. What about always having both the skos:narrower
and the corresponding skos:broader
statements in SkoHub Vocabs JSON-LD? Would this be a problem?
With these changes, skos:broader statements are replaced by the corresponding skos:narrower statements which are apparently needed to build the HTML view of a vocab. Thus, in the SkoHub version no skos:broader statements exist anymore.
This is another issue in your case where you are using hash URIs. The JSON is not based directly on the .ttl
but rather on the GraphQL queries. For the scheme, which is what we always deliver in case of hash URIs, we have only been building the tree with narrower
relations: https://github.com/skohub-io/skohub-vocabs/blob/a92b32324f3415b0520382afb9c9824275648b75/src/queries.js#L107
https://github.com/skohub-io/skohub-vocabs/pull/120/commits/1e9f8b2f19ac4c5bb3d975b1940344f6876eccfe changes that. I just realized that there are plenty of other fields missing from the ConceptScheme
JSON. The question is if we always want all fields in there. In case of slash URI schemes, it would make it unnecessarily big. We should discuss this in a separate issue though.
It took me some time to understand what you are talking about but I think I got it in the end. I agree that the ConceptScheme
JSON should, not be that detailed in case of slash URIs. It would probably make sense to have different ConceptScheme
JSON depending on whether we are dealing with hash or slash URIs. I opened #122 for this.
1+ for the changes in this PR. @dr0i, please deploy to production.
Oups, sorry @dr0i . Please deploy to test first as there is a change I haven't reveiwed yet.
@acka47 deployed to test.
For the scheme, which is what we always deliver in case of hash URIs, we have only been building the tree with
narrower
relations: https://github.com/skohub-io/skohub-vocabs/blob/a92b32324f3415b0520382afb9c9824275648b75/src/queries.js#L107https://github.com/skohub-io/skohub-vocabs/pull/120/commits/1e9f8b2f19ac4c5bb3d975b1940344f6876eccfe changes that.
By now, I am convinced that this does not make things much better. In a tree structure like JSON-LD, using the narrower
relationships alone and leaving out broader
makes a lot of sense. Instead of adding broader
we should rather think about adding those triples that contain additional information (#122). In other words, I suggest to revert the last commit and then deploy to production. What do you think, @literarymachine , @sroertgen?
By now, I am convinced that this does not make things much better. In a tree structure like JSON-LD, using the
narrower
relationships alone and leaving outbroader
makes a lot of sense. [...]
Right now no case comes to my mind, where I would explicitly need this. So for me this is okay.
I suggest to revert the last commit and then deploy to production. What do you think, @literarymachine , @sroertgen?
Done.
@dr0i Please deploy to production.
@literarymachine I would then open another issue for adding the inverse skos:related
links, right?
@literarymachine I would then open another issue for adding the inverse skos:related links, right?
Yes, I would say so. Are there any further properties that can be automatically added?
Are there any further properties that can be automatically added?
There are four owl:SymmetricProperty
s in SKOS: related
, relatedMatch
, closeMatch
, exactMatch
. As only one relation is between the concepts of the same vocab (related
), adding this automatically should suffice.
Deployed to production.
Symmetric properties as mentioned in https://github.com/skohub-io/skohub-vocabs/issues/105#issuecomment-720959194 could be added by considering them inverses of themselves.
Fixes #99