Is there a need for a rico:hasAccumulationDate object property?

[hopeaaron]

At the moment, it seems the only way to model dates of accumulation of a record resource in RiC-O is to employ the relation class rico:AccumulationRelation between the record resource and an agent, and to then link dates using rico:hasBeginningDate and rico:hasEndDate.

Is there a reason not to simply have rico:hasAccumulationDate as an object property, exactly as we already have with rico:hasCreationDate?

Thanks, Aaron Hope

[williamsonrichard]

Hi Aaron, nice question! I think the reason might be that for a given accumulation for which one wished to give both the accumulator and the date, then just using RecordSetA rico:hasAccumulator PersonB and RecordSetA rico:hasAccumulationDate DateC would lack a connection between the fact that DateC refers to the specific accumulation by PersonB, as opposed to any other accumulations (noting that hasAccumulator is M-to-M in RiC-CM). By using AccumulationRelation and rico:occurredAt, one is able to bind the date to the specific accumulation.

An alternative way to do it would be to introduce a new class to represent an Accumulation, and then one could have rico:occurredAtDate and rico:hasReceiver with source this class. But probably, since one has AccumulationRelation anyhow, this would be superfluous: there is a slight difference between the two approaches in that AccumulationRelation really requires specification of a receiver, whilst an Accumulation class a priori would not, but I can't immediately think of a compelling case where this extra generality would be useful here?

[hopeaaron]

Thanks Richard. I appreciate the logic of using the rico:AccumulationRelation and certainly agree it makes sense to bind particular accumulations to particular dates and accumulators. However, RiC-O doesn't seem to apply the same reasoning to dates of creation, which have both the object property rico:hasCreationDate and the class rico:CreationRelation. Wouldn't use of rico:hasCreationDate and rico:hasCreator cause the same lack of clarity for a record set with multiple creators?

On a more practical level, our existing dataset has a simple "dates of accumulation" field and I was thinking of how best to simplify the mapping and data conversion process!

Thanks again for your response.

[williamsonrichard]

Aha, thank you very much for your elaboration Aaron! I think now that you have a good point :-)! After all, if one has RecordSetA rico:hasAccumulationDate DateC, one can always in addition bind DateC to an AccumulationRelation via rico:occurredAtDate if one wishes to, and one can generically go the other way (obtain hasAccumulationDate by inference) via composition of properties; whilst, as you say, having hasAccumulationDate available directly may be convenient! Let's see what Florence thinks, I may be overlooking something, but currently I'm positive to the suggestion!

[florenceclavaud]

Hi @hopeaaron and @williamsonrichard, the rico:AccumulationRelation is a n-ary class implementation of the rico:hasAccumulator object property; both have existed since RiC-O 0.1, like other provenance binary and n-ary relations, which are core ones in RiC-O; they were necessary from that moment. While rico:hasCreationDate (and rico:hasOrHadAllMembersWithCreationDate, rico:hasOrHadSomeMembersWithCreationDate and rico:hasOrHadMostMembersWithCreationDate) was created recently, both in RiC-CM and RiC-O. At this stage of development, the absence of a rico:hasAccumulationDate subproperty of rico:isAssociatedWithDate (which would probably be less used than rico:hasCreationDate) simply results from this unfinished history ;-). Of course we can extend RiC-O in order to reach a more complete model for dates; we should in fact do so. This is noted! We will add this to the roadmap. Thank you @hopeaaron to emphasize this.

We could also review the model and consider defining other property chain axioms involving Record Resources, n-ary Relations and one single Date (or any n-ary Relation connected to one Date, as soon as the direct object property exists). This would be interesting I think. This would leave apart the implementations where dates are represented using datatype properties simply, which I suspect many projects use to store (and then query) date strings conforming to W3C date datatypes. Anyway, fortunately, when you implement RiC-O, you can also define, write and apply your own inference rules; RiC-O cannot anticipate any inference rule that could be useful in any specific projet for any dataset.

[williamsonrichard]

We could also review the model and consider defining other property chain axioms involving Record Resources, n-ary Relations and one single Date (or any n-ary Relation connected to one Date, as soon as the direct object property exists). This would be interesting I think.

Thank you for interpreting my rather poorly expressed thought in a much better way! Namely, I think something like making rico:hasCreationDate a sub-property of thingIsSourceOfRelation ∘ rico:creationRelation_role ∘ rico:occurredAtDate could be a very nice addition, and similarly for rico:hasAccumulationDate, etc.

Since rico:occurredAtDate has 'rico:Event' in its domain, a consequence of using this pattern would be that rico:CreationRelation would be inferred to be a rico:Event; this is probably not a disaster, but it could be that one wishes to be slightly more flexible and introduce 'rico:CreationEvent' and some object property from rico:CreationRelation to rico:CreationEvent (this could be done by rollification I think, but let us here just use rico:isAssociatedWithEvent), so that one would instead make rico:hasCreationDate a sub-property of thingIsSourceOfRelation ∘ rico:creationRelation_role ∘ rico:isAssociatedWithEvent ∘ rico:occurredAtDate.

One also has rico:isAssociatedWithDate that one could use directly with rico:CreationRelation, but the semantics seem to me slightly better if one makes use of rico:occurredAtDate and rico:Event.

Regarding datatypes, something that I do not understand in OWL DL is why it is not permitted to make a composition of properties in which the last one is a datatype property (I don't think this would cause any logical problems). If this were allowed, it would be possible to do things like make 'rico:creationDate' a sub-property of 'hasCreationDate ∘ rico:normalizedDateValue', which would tie together the object property and datatype property worlds rather nicely!

[florenceclavaud]

Since rico:occurredAtDate has 'rico:Event' in its domain, a consequence of using this pattern would be that rico:CreationRelation would be inferred to be a rico:Event; this is probably not a disaster, but it could be that one wishes to be slightly more flexible and introduce 'rico:CreationEvent' and some object property from rico:CreationRelation to rico:CreationEvent (this could be done by rollification I think, but let us here just use rico:isAssociatedWithEvent), so that one would instead make rico:hasCreationDate a sub-property of thingIsSourceOfRelation ∘ rico:creationRelation_role ∘ rico:isAssociatedWithEvent ∘ rico:occurredAtDate.

One also has rico:isAssociatedWithDate that one could use directly with rico:CreationRelation, but the semantics seem to me slightly better if one makes use of rico:occurredAtDate and rico:Event.

Hi @williamsonrichard, also, one could also use rico:hasBeginningDate and rico:hasEndDate to connect a Relation and Dates. As concerns your remark on rico:occurredAtDate having domain Event: quite a long time ago I had thought of articulating Event (and its subclass Activity), and at least some of the Relation classes. I had started to work on this, then could not find the time needed and put the topic aside. This topic is quite complex, and I would not be able for now to say what we may decide exactly at this stage (maybe nothing after all), but IMHO it would be worth thinking of it again. While some (at least) Relations can in a way be considered being states rather than events, from another perspective at least some of them, including the provenance ones, can be viewed as events or activities.

[williamsonrichard]

Hi @florenceclavaud, thank you very much, sounds very good! I agree that this is quite complex!