Make includesOrIncluded a subproperty of hasOrHadPart

[florenceclavaud]

For now, rico:includesOrIncluded, whose domain is Record Set and range the union of Record and Record Set, is not a subproperty of rico:hasOrHadPart; it is just a subproperty of the vague rico:isRecordResourceAssociatedWithRecordResource. This is exactly the same in RiC-CM 0.1. The rationale for this was that we had considered rico:hasOrHadPart a quite different kind of relation, that 'may affect the integrity or nature of the domain entity' - while a Record Set (for example a fonds or series) even if what it aggregates changes through time (for example if it includes, or loses, new series or new files), may often be considered the same entity. However this may raise important issues when you process massive legacy metadata sets (in particular EAD files) in order to convert them to RiC-O/RDF datasets. In those metadata sets, you cannot always decide, from the information you already have, if the description units you are processing describe Record Sets, or something else e.g. Records. And so, you have a problem, since you cannot choose whether you will use rico:includesOrIncluded or rico:hasOrHadConstituent (whose domain is Record and which is already a subproperty of rico:hasOrHadPart). Making rico:includesOrIncluded a subproperty of rico:hasOrHasPart would group all the aggregation or composition subproperties under the same superproperty; this would be more consistent and would allow, in the situations described above, to use rico:hasOrHadPart. It would also help when you have to query the datasets. Another idea would be to only keep rico:hasOrHadConstituent, and extend its domains and ranges. On which I am not sure I would agree.

[florenceclavaud]

A few more words: of course if such a decision is made, it may also imply that the definition of hasOrHadPArt is updated. And it will imply that the same change is made in RiC-CM 1.0.

[williamsonrichard]

Great that you take up this!

A case where this has cropped up for us is in the modelling of 'hybrid archives' with both paper and a digital record sets as part of them. We have currently modelled the (hybrid) archive as a whole as a record set as well, with the relation of the paper and digital record sets to it being expressed by hasOrHadPart. The definition of hasOrHadPart seems to encompass this ('Connects a thing to a thing that is a constitutive ... part of it').

But I now see that perhaps the intention in RiC was that we should model this instead by includesOrIncluded. I think that others will make this mistake, if indeed it is a mistake.

Another idea would be to only keep one of these 2 relations, rico:includesOrIncluded and rico:hasOrHadConstituent, and extend their domains and ranges. On which I am not sure I would agree.

I agree with your inclination to disagree! I think there is a different semantics in saying that entity A belongs to entity B without entity A being able to be considered as being of the same type as entity B (a sheet of paper (entity A) belonging to a deed (entity B), for instance), than in saying that entity A can be considered as being of the same type as entity B (like in the hybrid archive case I mentioned). The former would be hasOrHadConstituent, the latter could be includesOrIncluded, but I completely agree that the latter must then be considered a sub-property of hasOrHadPart. It makes no sense to me quibble over any differences there given the definition of hasOrHadPart that I quoted.

[dpitti]

See a “devil’s advocate” observation below.

From: Florence Clavaud @.> Reply-To: ICA-EGAD/RiC-O @.> Date: Friday, April 28, 2023 at 9:22 AM To: ICA-EGAD/RiC-O @.> Cc: Subscribed @.> Subject: [ICA-EGAD/RiC-O] Make includesOrIncluded a subproperty of hasOrHadPart (Issue #55)

For now, rico:includesOrIncluded, whose domain is Record Set and range the union of Record and Record Set, is not a subproperty of rico:hasOrHadPart, it is just a subproperty of the vague rico:isRecordResourceAssociatedWithRecordResource. This is exactly the same in RiC-CM 0.1. The rationale for this was that we had considered rico:hasOrHadPart a quite different kind of relation, that 'may affect the integrity or nature of the domain entity' - while a Record Set (for example a fonds or series) even if what it aggregates changes through time (for example if it includes, or loses, new series or new files), may often be considered the same entity. However this may raise important issues when you process massive legacy metadata sets (in particular EAD files) in order to convert them to RiC-O/RDF datasets. In those metadata sets, you cannot always decide, from the information you already have, if the description units you are processing describe Record Sets, or something else e.g. Records. And so, you have a problem, since you cannot choose whether you will use rico:includesOrIncluded or rico:hasOrHadConstituent (whose domain is Record).

====if you do not know, then I would think the “safe” property/relation would be rico:isRecordResourceAssociatedWithRecordResource.

Making rico:includesOrIncluded a subproperty of rico:hasOrHasPart would allow you, in such situations, to have a solution (and use rico:hasOrHadPart). Another idea would be to only keep one of these 2 relations, rico:includesOrIncluded and rico:hasOrHadConstituent, and extend their domains and ranges. On which I am not sure I would agree.

— Reply to this email directly, view it on GitHubhttps://github.com/ICA-EGAD/RiC-O/issues/55, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAMUL7ZZKDQLSWCFQQ3IIK3XDPAALANCNFSM6AAAAAAXPHROTU. You are receiving this because you are subscribed to this thread.Message ID: @.***>

[williamsonrichard]

====if you do not know, then I would think the “safe” property/relation would be rico:isRecordResourceAssociatedWithRecordResource

In my opinion this object property is almost too vague to ever be very useful in itself (in what way is the one record resource associated with the other?). It can be useful as a means to connect different ways of record resources being associated with one another, e.g. one might use it in a SPARQL query, so it is good that it exists, but when one is actually modelling one should surely always aim to use a more specific sub-property.

[florenceclavaud]

====if you do not know, then I would think the “safe” property/relation would be rico:isRecordResourceAssociatedWithRecordResource

In my opinion this object property is almost too vague to ever be very useful in itself (in what way is it associated?). It can be useful as a means to connect different ways of record resources being associated with one another, e.g. one might use it in a SPARQL query, but when one actually modelling one should surely always aim to use a more specific sub-property.

Yes, I agree, it is too vague to replace an aggregation relation, and would not be really useful in the case we are talking about.

Also, the definition of hasOrHadPart only says 'The end of existence of a whole/part relation may affect the integrity or nature of the domain entity' - this is what I had written for RiC-CM 0.2 in fact. The verb used is 'may' ;-) So IMHO this allows us to make the change I suggest above.

[smluke2]

@florenceclavaud , where is the document that we are working on for this? I apologize. I am still becoming familiar with where everything is located.

[florenceclavaud]

Hi @smluke2, it is the RiC-O 1.0 file that you can find here: https://github.com/ICA-EGAD/RiC-O/tree/version_1-0/ontology/current-version (in the version_1-0 branch, in the ontology/current-version subfolder). So you could create a branch (see https://docs.github.com/en/get-started/quickstart/github-glossary#branch) from this version_1-0 branch, using GitHub directly online, naming it e.g. issue-55-includesOrIncluded, than checkout this branch (switch to this branch) on your local repo on your computer, than work on this file before committing what you have done to this specific branch in the GitHub repo. @ivozandhuis can also do this and then you check what he did, or you could work on this together. I hope this helps! Thank you!

[florenceclavaud]

The two concerned object properties have been made subproperties of both isRecordResourceAssociatedWithRecordResource and hasOrHadPart or isOrWasPartOf. I am closing this as completed.