search

skohub-io / skohub-vocabs

A lightweight tool to publish SKOS Vocabularies
https://skohub.io/
Apache License 2.0
32 stars 25 forks source link

Two URIs for `skos:inScheme` breaks building of concept page #255

Closed sroertgen closed 1 year ago

sroertgen commented 1 year ago

During working on #254 with the NALT dataset I also noticed that giving two URIs for skos:inScheme break the build of the concept page for that vocab.

This seems to be, because inScheme is not defined as an array in types.js.

Since it is totally valid to have multiple URIs for skos:inScheme and the above dataset uses it this way, this should be fixed.

Maybe we should also show this information on the Concept page.

sroertgen commented 1 year ago

@acka47 Working on this I noticed that it is not totally clear to me, how this should best be implemented in SkoHub Vocabs. Should we demand that all ConceptSchemes that are linked to with skos:inScheme are also present somewehere in the data or would it also be okay to have a link to a concept scheme that is not present in the provided turtle files?

The latter would maybe be a little problematic for SkoHub Vocabs at the moment since it currently considers all linked Concept Schemes to present in the data layer. But if it would be desired that we can have multiple concept schemes and not all need to be present in the data, I will have to think on how to implement this.

acka47 commented 1 year ago

What is the actual use case/example we need to implement this for? I'd like to take a look at it before making a decision.

sroertgen commented 1 year ago

Thinking about Tom's use case for reconciliation I noticed that his mentioned NALT vocabularies would currently not build using SkoHub Vocabs. This vocab has two concept schemes in one file (adressed with #254) and a lot of concepts are present in one as well as in the other concept scheme.

So for this vocab it would be the case that both concept schemes are also present in the data.

acka47 commented 1 year ago

So for this vocab it would be the case that both concept schemes are also present in the data.

Let's first address this use case then where both concept schemes are described and contained in the repo that we build from.

We can at a later point add these use cases:

  1. both vocabs are published with the same SkoHub instance but are not maintained in the same repo
  2. the vocabs are published via different SkoHub instances
  3. one of the vocabs is published with a solution other than SkoHub