You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
raiseValueError(
'You are searching for items in an unexisting collection.'
)
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: