Generic pattern for associating relations to dates #130
Conversation
williamsonrichard
commented
Dec 19, 2024
williamsonrichard
commented
- We introduce a 'relationHasDate' object property which allows a relation to be associated to a date, and an inverse to it.
- We introduce a new object property 'hasDateAssociatedWithOrganicProvenance' and make both 'hasCreationDate' and 'hasAccumulationDate' a sub-property of it; similarly for their inverses.
- We connect all three of these object properties and their inverses to the OrganicProvenance, CreationRelation, and AccumulationRelation classes respectively by means of sub-property chains involving the new object property 'relationHasDate' and its inverse.
1. We introduce a 'relationHasDate' object property which allows a relation to be associated to a date, and an inverse to it. 2. We introduce a new object property 'hasDateAssociatedWithOrganicProvenance' and make both 'hasCreationDate' and 'hasAccumulationDate' a sub-property of it; similarly for their inverses. 3. We connect all three of these object properties and their inverses to the OrganicProvenance, CreationRelation, and AccumulationRelation classes respectively by means of sub-property chains involving the new object property 'relationHasDate' and its inverse.
|
@florenceclavaud Over email a while back, we touched upon the possibility of generalising this pattern at least to AuthorshipRelation (i.e. introducing hasAuthorshipDate and connecting it to AuthorshipRelation in the same pattern as introduced here), and e.g. also introducing CollectionRelation and ReceptionRelation with corresponding date object properties in the same pattern, connecting these to hasCollector and hasReceiver and their inverses as well. In this way all sub-properties related to organic provenance would be handled in the same way. Let me know if you'd like me to do some or all of this in this pull request or a later one! I have also not implemented your nice idea of 'wasActiveAtDate' yet, I can do that in a later pull request, so that we can focus in this pull request on whether the overall pattern is OK! How should we handle 'hasOrHadSomeMembersWithCreationDate' and so on? Is it appropriate to introduce (exactly) the same sub-property chain as for 'hasCreationDate' and so on here? My guess is that it is fine, but I'd like to hear what you think! Finally, I was unsure whether to make 'relationHasDate' a sub-property of 'relationConnects' or 'relationHasContext'. I chose the former for now, as 'relationHasContext' refers to 'secondary entities', and the scope note gives 'Position' and 'RoleType' as examples of what 'secondary' means; I am not sure whether you intend dates to be secondary in this sense. Just let me know if you'd prefer 'relationHasContext' to be used, and I can then change it to this and update the scope note to include dates. |
Hi @williamsonrichard, yes we could do this; a new pull request would be better IMHO! |
IMHO 'relationHasDate' should be a subproperty of 'relationHasContext'. 'relationHasSource' and 'relationHasTarget' are the only properties that are definitely needed on such n-ary Relation classes, since they extend in a way (some would say reify but I prefer extend) the binary corresponding properties (e.g. 'hasOrganicProvenance'). 'isEvidencedBy' is quite specific (metadata of the relation). The other ones link the relation to other entities possibly involved, among which Position, Date and Place (Place, in the future....). |
Yes, it would be great, and a new PR would be appropriate I think (this is about the PerformanceRelation). |
Yes I think the same pattern should theoretically be applied to those 'all/some' properties. However, finding good names for the Relation classes involved may be complicated... Also, IMHO it is not so urgent. It seems that those properties are not widely used yet. Maybe we could wait. Applying the pattern to AuthorshipRelation, and to new Collection and Reception relations, as well as adding wasActiveAtDate, is more important IMHO. |
| @@ -1921,6 +1921,23 @@ | |||
| </rdf:Description> | |||
| </skos:changeNote> | |||
| </owl:ObjectProperty> | |||
| <!-- https://www.ica.org/standards/RiC/ontology#dateAssociatedWithRelation --> | |||
There was a problem hiding this comment.
Or maybe 'isDateAssociatedWithRelation', like for other date properties of the kind (I know I'm splitting hairs...)
| @@ -16083,6 +16202,23 @@ | |||
| <skos:scopeNote xml:lang="en">The secondary entity may be, for instance, a Position or a | |||
| Role Type.</skos:scopeNote> | |||
| </owl:ObjectProperty> | |||
| <!-- https://www.ica.org/standards/RiC/ontology#relationHasDate --> | |||
| <owl:ObjectProperty rdf:about="https://www.ica.org/standards/RiC/ontology#relationHasDate"> | |||
| <rdfs:subPropertyOf rdf:resource="https://www.ica.org/standards/RiC/ontology#relationHasConnects"/> | |||
There was a problem hiding this comment.
subproperty of relationHasContext (also, relationHasConnects does not exist ;-))
| @@ -7524,6 +7564,34 @@ | |||
| <RiCCMCorrespondingComponent xml:lang="en">RiC-R026 ('has provenance' | |||
| relation)</RiCCMCorrespondingComponent> | |||
| </owl:ObjectProperty> | |||
| <!-- https://www.ica.org/standards/RiC/ontology#hasDateAssociatedWithOrganicProvenance --> | |||
There was a problem hiding this comment.
or maybe hasOrganicProvenanceDate (same, I am splitting hairs, but IMHP it is simpler and sounds better)
| @@ -9510,6 +9601,34 @@ | |||
| <RiCCMCorrespondingComponent xml:lang="en">RiC-R068 ('is date associated with' | |||
| relation)</RiCCMCorrespondingComponent> | |||
| </owl:ObjectProperty> | |||
| <!-- https://www.ica.org/standards/RiC/ontology#isDateAssociatedWithOrganicProvenanceOf --> | |||
There was a problem hiding this comment.
or 'isOrganicProvenanceDateOf'
