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

Dealing with Collections #7

Closed
koenedaele opened this issue Oct 3, 2014 · 0 comments
Closed

Dealing with Collections #7

koenedaele opened this issue Oct 3, 2014 · 0 comments
Assignees
Milestone

Comments

@koenedaele
Copy link
Member

Currently the services at heritagedata.org don't provide collections. They are actually present in the core vocabularies before transformation to SKOS, but were modelled as Concepts because of the issues in SKOS with hierarchical relations between Collections and Concepts (the inability to specify under which Concept a Collection should be displayed in a hierarchy). This might change in a future version of heritagedata.org. It might be possible to use the ISO-THES standard there just as we did for our skosprovider.

Our current implementation does not allow querying for a Collection. I'd rather see it follow the normal skosprovider contract, but return nothing.

So, if a user is looking for 'type' == 'collection', do not raise an error, but just return an empty list and provide a warning.

Similarly, if a user is looking for collection = {'id': 15, depth:'all'}, provide the same answer as a standard skosprovider and provide a warning to the user that this skosprovider doesn't have any collections anyway, so the query is probably wrong.

raise ValueError(
    'You are searching for items in an unexisting collection.'
)
@koenedaele koenedaele added this to the 0.1.0 milestone Oct 3, 2014
@dieuska dieuska closed this as completed in af17c9d Oct 7, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants