-
Notifications
You must be signed in to change notification settings - Fork 0
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
Create separate class for acdh:hasSubject range #35
Comments
Could you please explain why? We are aiming for a dedicated vocabulary for acdh:hasSubject and then we would have something similar to acdh:hasLanguage or acdh:hasLicense, which make use of skos:Concept. What would be different in the case with acdh:hasSubject? Btw: We had a class 'Concept' in the early days of the ontology and decided to kick it out at some point |
We were thinking with Seta about a different way of defining vocabularies for properties. Now we need:
On the other hand we already have in place an URI checking mechanism where for a given ARCHE class we define a set of allowed external authority files (e.g. a Person can be identified by an URI in the acdhi, viaf, gnd, etc. namespace). This method allows to easily combine multiple sources and it doesn't require to materialize all possible values as ARCHE resources. Just as the rules system is based on ARCHE class being a range of a given property, a distinct set of rules requires a dedicated class to be defined. What's worth noting it would be just a helper class like dozens we have already for defining property inheritance and cardinality constrains. |
Anyway, at the moment |
and change acdh:hasLanguage range to it. This will allow us to test the scenario described in #35
Having a separate class for the acdh:hasSubject range will allow us to define separate doorkeeper check rules for the values.
acdh-oeaw/arche-doorkeeper#32
acdh-oeaw/arche-ref-sources#13
The text was updated successfully, but these errors were encountered: