Two URIs for `skos:inScheme` breaks building of concept page about skohub-vocabs HOT 4 CLOSED

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

from skohub-vocabs.

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

from skohub-vocabs.

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.

from skohub-vocabs.

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.

from skohub-vocabs.