Expected behavior of using multiple skos:ConceptSchemes in one file

[rmfranken]

Hi there,

I see there is support for multiple SKOS concept schemes in one file: I can separate terms belonging to various specific domains like that. However, it seems sort of moot, because all terms are still in the tree - regardless of which concept scheme I'm exploring. The only difference being the presence of a inScheme entry for the term pointing to the concept schemes it's part of.

I would expect that browsing concept scheme A would only show terms that are in that concept scheme. For an example:

https://dac-portal-f3466e.gitlab.io/schema/

I have 2 concept schemes here, if you browse to the https://ontology.swisscustodian.ch/schema/PaymentCommitment object, you can see this is only in LUCID concept scheme - yet I can browse there from the FEGA concept scheme too.

Is this desired/expected behavior? To me, it would be much more powerful if I can use a single file containing multiple concept schemes, and that skohub is able to split the ui accordingly.

[acka47]

Thanks for the report. Interesting and I would say this isn't expected behaviour. As far as I understand it, you should be able to spread your RDF over as many ttl files as you like. To investigate this, we need to see the underlying Turtle file this is built from. Can you add a link to it?

[rmfranken]

https://gitlab.com/data-custodian/custodian/-/raw/main/components/ontology/gen/fega/ontology.ttl?ref_type=heads

This should be publicly accessible :)

[rmfranken]

And just to be clear my issue is:

The union of however many files (in my case just 1) contains multiple skos:ConceptScheme instances -> ✔️ I get a homepage like dac-portal-f3466e.gitlab.io/schema -> ✔️ I click on one of the concept schemes and -> ❗ I still see the same tree with all concepts from both concept schemes.

[rmfranken]

More context: I've "fixed" this behavior in our fork. (this is somewhat vibe-coded) The tests are also not generic - they are based on my usecase of custodian.

5a8a8cd