Define subclasses of Event and Activity more rigorously #6
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
State explicitly whether a given event type relates to Item, Manifestation, or WorkVariant.
State explicitly whether a given activity type relates to Item, Manifestation, or WorkVariant.
Section D.4.1 of the Cataloguing Manual seems to associate locations with publication events only. Broadening the domain may not do much harm or even be desirable but the decision (and reasoning) should perhaps be documented somewhere. At any rate, broadening the domain in a later version of the ontology would preserve backwards compatibility, whereas restricting it from Event to PublicationEvent later would break compatibility.
Author
|
I forgot to mention that I declared WorkVariant, Manifestation and |
Author
|
And here you can view the proposed changes: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Even though the domain of the property hasEvent includes items,
manifestations and work/variants, the Cataloguing Manual provides a
number of strict guidelines associating certain subclasses of Event
with instances of Manifestation only, others with instances of Item
only, and so on. Similarly for the property hasActivity.
This pull request tries to make the ontology reflect those guidelines
more accurately. The Cataloguing Manual appears to be far less
specific in other respects. For instance, the same values for colour
or sound characteristic may be recorded for manifestations or items.
Accordingly, the ontology cannot impose further restrictions on the
hasColourCharacteristic property. In fact, I have reviewed the list of
properties whose domain consists of a union of classes, and I was
unable to identify any property beside hasEvent and hasActivity that
comes with further "obvious" restrictions according to the Cataloguing
Manual.
On the other hand, the domain of the hasEventLocation property is
defined as Event even though the cited section of the manual (D.4.1)
seems to relate locations to publication events only. That is why I
have restricted hasEventLocation to PublicationEvent. If you have
discussed this before and deliberately chosen to define the domain as
Event rather than PublicationEvent, I can remove this change from the
pull request again. Generally speaking, there may be more properties
whose domain consists of a single class that may or even should be
replaced by a more specific subclass; naturally, they are hard to find
and therefore out of scope for this pull request.