Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove topConcept from KBV ontology #353

Open
wants to merge 1 commit into
base: develop
Choose a base branch
from

Conversation

klngwll
Copy link
Contributor

@klngwll klngwll commented Dec 9, 2021

Remove skos:hasTopConcept from KBV ontology.

Comment on lines -31 to -38
# 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 .


Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there anything hardcoded in the cataloguing client which would benefit from anything like this though? 🤔

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nope, no references at all to hasTopConcept in the UI code.

Copy link
Contributor

@oBlissing oBlissing Dec 10, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

@klngwll klngwll Dec 15, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we discover more than one context, we could define different skos:Collections instead, listing classes of interest (for the then presumably documented contexts).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants