Infer skos:narrower relations

[literarymachine]

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

[sroertgen]

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.

[literarymachine]

I was getting this error with your branch

+1, thanks @sroertgen. I was using unsuitable test data.

[acka47]

@dr0i Please deploy to test.

[dr0i]

Deployed to test.

[acka47]

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?

[literarymachine]

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.

[acka47]

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.

[acka47]

Oups, sorry @dr0i . Please deploy to test first as there is a change I haven't reveiwed yet.

[dr0i]

@acka47 deployed to test.

[acka47]

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.

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?

[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 out broader 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.

[literarymachine]

I suggest to revert the last commit and then deploy to production. What do you think, @literarymachine , @sroertgen?

Done.

[acka47]

@dr0i Please deploy to production.

@literarymachine I would then open another issue for adding the inverse skos:related links, right?

[literarymachine]

@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?

[acka47]

Are there any further properties that can be automatically added?

There are four owl:SymmetricPropertys in SKOS: related, relatedMatch, closeMatch, exactMatch. As only one relation is between the concepts of the same vocab (related), adding this automatically should suffice.

[dr0i]

Deployed to production.