Lacking properties - place of birth/death

[yaeln]

Hi, We are new to RiC-O, and are aiming to use it in our implementation of a digital personal archive. In our work, we code metadata not only for the documents but also of authorities such as persons and organizations. We found that there are 'date of birth/death' among the properties of Person but not 'place of birth/death'. The question is if it is possible to add those (or in general, discuss this elaboration). Thank you very much!

Keren Shuster and Yael Netzer

[ivozandhuis]

The Linked Data framework allows you to combine ontologies. You might consider borrowing properties from schema.org for modelling more elaborate personal information. See: http://schema.org/Person

[yaeln]

Of course, this is an option, only that we were thinking about the consistency, or the motivation for including certain properties and not other - in this case biographical details, because we can find also birthDate / deathDate in http://schema.org/Person.

[ivozandhuis]

Good point.

[florenceclavaud]

As a matter of fact, I think EGAD should add these properties to RiC-O, as we already have a quite wide range of properties for describing persons, and as these two ones are missing and are relevant in the RiC framework. We want to provide RiC implementers and users with a comprehensive model, as explained in https://ica-egad.github.io/RiC-O/why-use-RiC-O.html. Let me add that, as said in https://ica-egad.github.io/RiC-O/next-steps.html, we will certainly map RiC-O and schema.org (among other ontologies).

[wildit]

By the way: There is a project in Switzerland that currently works on the mapping pipeline from RiC to schema.org. It's a research infrastructure for all kind of open research data, called Connectome (https://www.switch.ch/connectome/). Connectome is based on schema.org, see https://rescs.org/dev/entities-tree-classes.html and the SCHAL Shapes: https://github.com/Connectome-Consortium/rescs_shacl_shapes. @tobiasschweizer from SWITCH can tell you more.

In the case of Connectome, RiC is being used as an intermediary format for libraries and archives who want to integrate their catalogue data into Connectome. I work eg. on the mapper for Marcxml -> RiC for https://patrinum.ch/.

I'm interested to discuss the inconsistencies between RiC and schema.org and possible ways to combine the two. We will have this issue in all kind of fields, because RiC has to draw its boundaries somewhere and then work topgether with other ontologies. Other fields would be technical metadata (Premis) or controlled vocabularies (Skos).

[florenceclavaud]

Good to learn this about Schema.org, Tobias! We need to talk about this. As concerns PREMIS, I have just (at least) sent an email to PREMIS editorial committee in order to start the discussion on mapping RiC (and RiC-O) and PREMIS data dictionary and ontology. Same as for Schema.org, it is in RiC-O roadmap; I think this is strategic targets for RiC-O and its users. It should (hopefully) be included in RiC-O 1.0. As concerns SKOS, I am not sure we need to map SKOS and RiC-O. It is already possible to use RiC-O in combination with SKOS. We have been doing this at the Archives nationales of France for several years; see for example https://github.com/ArchivesNationalesFR/Referentiels.

[dpitti]

Dear Florence and Tobias,

In light the recent discussion about additional properties with regard to persons, in SNAC we started with RiC relations and then extend with more precise relations in many places, based on what SNAC editors requested and we reviewed.

See https://docs.google.com/spreadsheets/d/1829n1j9gvDOw3aw98ssZxxyVLpS-XuJn11_J9y_rQrU/edit?usp=sharing

I would appreciate you reviewing this table. It does not include all RiC relations, just a subset, and then the subset extended.

Instead of “nationality” we have created two relations between Agent and Place: “has identity place” and “has ancestry place”

In discussing this, an American of Korean ancestry suggested “has ancestry place”, as she said I am an American, though do have ancestors from Korea. Given the vast majority of Americans are the descendants of people from all over the world, we thought this a very flexible way to address the complexities. I, for example, have Ireland and Italy as ancestry places.

Regards, Daniel

From: Florence Clavaud @.> Reply-To: ICA-EGAD/RiC-O @.> Date: Friday, February 25, 2022 at 4:27 AM To: ICA-EGAD/RiC-O @.> Cc: Subscribed @.> Subject: Re: [ICA-EGAD/RiC-O] Lacking properties - place of birth/death (Issue #34)

Good to learn this about Schema.org, Tobias! We need to talk about this. As concerns PREMIS, I have just (at least) sent an email to PREMIS editorial committee in order to start the discussion on mapping RiC (and RiC-O) and PREMIS data dictionary and ontology. Same as for Schema.org, it is in RiC-O roadmap; I think this is strategic targets for RiC-O and its users. It should (hopefully) be included in RiC-O 1.0. As concerns SKOS, I am not sure we need to map SKOS and RiC-O. It is already possible to use RiC-O in combination with SKOS. We have been doing this at the Archives nationales of France for several years; see for example https://github.com/ArchivesNationalesFR/Referentiels.

— Reply to this email directly, view it on GitHubhttps://github.com/ICA-EGAD/RiC-O/issues/34#issuecomment-1050683461, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAMUL76IGX7NNU7JIW2YFDDU45DOJANCNFSM5OAMA2AA. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you are subscribed to this thread.Message ID: @.***>

[florenceclavaud]

OK, there is much to think and do there. For now:

• I will just create an issue, with as milestone 'after RiC-0 1.0', in order to have a placeholder to work on how RiC-O and schema.org can be combined or mapped.
• I suggest, as @yaeln asked for it a long time ago, and as the discussion brought quite strong arguments, that we add hasBirthPlace and hasDeathPlace, and the inverse properties, to RiC-O 1-0.
• As concerns the table on SNAC relations: we could discuss this later on: however I would consider already adding hasOrHadEmployer to RiC-O, which would imply that we choose its superproperties. We already have hasOrHadController, hasOrHadMember, hasOrHadWorkRelationWith. I would vote for making this new property a subproperty of the hasOrHadController and hasOrHadMember at least. Any thoughts?

[florenceclavaud]

I have created the issue on mapping/combining RiC-O and schema.org (see #72)

[florenceclavaud]

I am closing this issue, as:

• hasOrHadEmployer has been created along with its inverse property
• placeIsAssociatedWithAgent has been added, with isBirthPlaceOf, isDeathPlaceOf and isOrWasLocationOfAgent subproperties - among other that already existed like isOrWasJurisdictionOf ; and of course the inverse ones. This was done with #79