-
Notifications
You must be signed in to change notification settings - Fork 47
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
Dcat issue 1364 second solution #1379
Conversation
…t:theme, and changing a usage note
This looks clean and sensible to me |
@andrea-perego can you check the rephasing of the note before defining |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, @riccardoAlbertoni .
+1 from me. I just suggested an editorial change.
Co-authored-by: Andrea Perego <[email protected]>
Thanks, Andrea. I have accepted your suggestion. |
@davebrowning , @pwin , @agbeltran , Is this PR ok for you? |
…nd resolving the conflict with pr #1379
An alternative solution to PR #1380
This PR drops the range for
dcat:theme
, but explicitly defining it asowl:ObjectProperty
as suggested by @dr-shorthair in #1364 (comment)Considering that
dcterm:subject
has been recently changed to let both literals and URI, by definingdcat:theme
s as anowl:ObjectProperty
and dropping thedcat:theme
's range,dcat:theme
would still restrictdcterms:subject
to URIs, whiledcat:keyword
might restrictdcterms:subject
to literals.This would also limit the automatic inference of
skos:Concept
, which could be potentially problematic when applied to instances whose classes are defined disjoint fromskos:Concept
.