Remove topConcept from KBV ontology #353
Conversation
| # TODO: List top concepts to provide interfaces with: | ||
| # - a set of starting points for e.g. navigation, creation | ||
| # - a "roof" when finding base classes | ||
| #: skos:hasTopConcept :Work . | ||
| #: skos:hasTopConcept :Instance . | ||
| ##: skos:hasTopConcept :Print . | ||
|
|
||
|
|
There was a problem hiding this comment.
Is there anything hardcoded in the cataloguing client which would benefit from anything like this though? 🤔
There was a problem hiding this comment.
Nope, no references at all to hasTopConcept in the UI code.
There was a problem hiding this comment.
Did I understand the question? We do have some similar things hardcoded:
https://github.com/libris/lxlviewer/blob/develop/lxljs/vocab.js#L169-L191
These things should probably be defined in the vocab instead, yes.
There was a problem hiding this comment.
@oBlissing Yeah the idea was if there was any function in for example viewer that would need something like that, we are still a bit unsure how this would translate to different contexts especially for Concept.
There was a problem hiding this comment.
If we discover more than one context, we could define different skos:Collections instead, listing classes of interest (for the then presumably documented contexts).
Remove
skos:hasTopConceptfrom KBV ontology.