Role - how to describe this.
Ann Attwood
CLAVAUD Florence
Envoyé : samedi 27 juin 2026 10:38
À : Records_in_Contexts_users <records_in_c...@googlegroups.com>
Objet : [Records in Contexts users] Role - how to describe this.
|
Vous n’obtenez pas souvent d’e-mail à partir de ann.attw...@gmail.com.
Pourquoi c’est important
|
|
⚠
Expéditeur Externe au ministère de la Culture. Ne cliquez sur aucun lien et n'ouvrez aucune pièce jointe à moins que vous ne reconnaissiez l'expéditeur et que vous soyez sûr que le contenu est sans
danger.
|
You received this message because you are subscribed to the Google Groups "Records_in_Contexts_users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to Records_in_Context...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/Records_in_Contexts_users/175471b2-7f4f-4f8e-ae38-78840fe9dc60n%40googlegroups.com.
Merci de nous aider à préserver l'environnement en n'imprimant ce courriel et les documents joints que si nécessaire.
Ivo Zandhuis
For your problem the Dutch center for family history has developed a
dedicated datamodel called "Persons in Context" (PiCo). (Notice where
they got inspired for a name :-) It is described elaborately in this
paper: https://hlcs.nl/article/view/19312
The standard reuses as much existing properties as possible, in order
for existing software that is aware of these properties to use the data.
For family relations we've introduced a list of possible relations. One
of them is <https://personsincontext.org/model#hasFosterParent> and its
inverse <https://personsincontext.org/model#hasFosterChild>
Interesting you distinguish "adoptive parent" and "foster parent". We
were not aware of a distinction between the two and have not come across
a use case for it yet, so please let us know if you need a separate
adoptive parent relation and we'll discus it in the board.
In pico the example Florence gave would look like this:
@prefix prov: <http://www.w3.org/ns/prov#> .
@prefix sdo: <https://schema.org/> .
@prefix pnv: <https://w3id.org/pnv#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix picom: <https://personsincontext.org/model#> .
@prefix picot_sourcetypes:
<https://terms.personsincontext.org/sourcetypes/> .
@prefix picot_eventtypes:
<https://terms.personsincontext.org/eventtypes/> .
@prefix picot_roles: <https://terms.personsincontext.org/roles/> .
my-data:jane_doe
a picom:PersonObservation, sdo:Person ;
prov:hadPrimarySource
my-data:archival-source-where-this-person-is-mentioned ;
sdo:name "Jane Doe"@en ;
sdo:familyName "Doe" ;
sdo:givenName "Jane" ;
sdo:gender sdo:Female ;
picom:hasRole picot_roles:574 ; # bride/groom
picom:hasLifeEvent my-data:JaneDoeWedding189006 .
my-data:jane_doe_wedding189006
a picom:LifeEvent ;
picom:eventType picot_eventtypes:83 ; # marriage
picom:eventDate "1890"^^xsd:gYear .
Pico requires to relate the archival source where you've found the
mentioning of a Jane Doe. At least in simple Schema.org statements, but
off course a more elaborate and appropriate description should be
published in RiCo.
Hope this helps.
Best regards,
Ivo Zandhuis
CLAVAUD Florence schreef op 2026-07-09 14:55:
>
> The properties that are defined in RiC-O 1.1 and have a IRI ending by
> “_role” are not what you are looking for. Each of these properties
> is a reflexive property having a rico:Relation class as domain and
> range. We added these very specific properties in RiC-O 1.0 to get
> something more compact and easier to maintain that what we had before
> in the system of Relation classes and properties defined for these
> relations (including the ‘shortcuts’). This is a bit technical but
> on this topic, you could have a look at
> https://ica-egad.github.io/RiC-O/migrating-data-from-RIC-O-v0.2-to-v1.0.html#changes-made-to-the-system-of-relation-classes
> I do not think using rico:Position would be a solution, as a Position
> connects a person and a group, not two persons to each other.
> You could also, in addition, use a rico:FamilyRelation, as an
> intermediate node to connect the two persons concerned, which would
> allow you to describe the relation and to record the dates when the
> two persons started (and possibly ended) to have a relation of the
> kind.
> Of course, if you also are describing the family (as an instance of
> rico:Family), each of the persons concerned can be connected to the
> family using rico:isOrWasMemberOf (and possibly an instance of
> rico:MembershipRelation between the person and the family).
>
> My two cents. Hope this helps you!
>
> Best regards,
>
> Florence Clavaud
> Chair of ICA/EGAD, lead of RiC-O development team
>
> De : records_in_c...@googlegroups.com
> <records_in_c...@googlegroups.com> de la part de Ann Attwood
> <ann.attw...@gmail.com>
> Envoyé : samedi 27 juin 2026 10:38
> À : Records_in_Contexts_users
> <records_in_c...@googlegroups.com>
> Objet : [Records in Contexts users] Role - how to describe this.
>
> Vous n’obtenez pas souvent d’e-mail à partir de
>
> -------------------------
> courriel et les documents joints que si nécessaire.
>
> You received this message because you are subscribed to the Google
> Groups "Records_in_Contexts_users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to Records_in_Context...@googlegroups.com.
> To view this discussion visit
> [5].
>
>
> Links:
> ------
> [1]
> https://ica-egad.github.io/RiC-O/migrating-data-from-RIC-O-v0.2-to-v1.0.html#changes-made-to-the-system-of-relation-classes
> [2] https://ica-egad.github.io/RiC-AG/faq--how_to_extend_ric.html
> [3] https://aka.ms/LearnAboutSenderIdentification
> [4]
> https://urldefense.com/v3/__https://groups.google.com/d/msgid/Records_in_Contexts_users/175471b2-7f4f-4f8e-ae38-78840fe9dc60n*40googlegroups.com?utm_medium=email&utm_source=footer__;JQ!!Gnbj7qdtAHuaEg!u-Cw2qo-3syClRvFQ4f32m2zBkQy9O39tcUyv-bK-2jWsK-f_V2pE6k0k5TZwcYsveY4b-oFSfoHO7GQd2_eSSMnfFdVw5aVSLb_86DG$
> [5]
> https://groups.google.com/d/msgid/Records_in_Contexts_users/PAZP264MB2431D02FB238CAAE002B9E12D5FE2%40PAZP264MB2431.FRAP264.PROD.OUTLOOK.COM?utm_medium=email&utm_source=footer
---
Ivo Zandhuis, PhD
Freelance consultant - Digital • Heritage • Humanities
Research Fellow - International Institute of Social History
Johan Pieterse
Dear Ann,
Florence's EventRelation answer is exactly the pattern I would use too, and I wanted to add a practical note: we've now implemented it in OpenRiC (the open reference implementation at ric.theahg.co.za), so you can see the shape working end to end and reuse the extension rather than defining it from scratch.
On the role in an event ("bride" at a wedding)
Florence is right that the `_role` object properties (`rico:eventRelation_role` etc.) are not what you want, those are the reflexive relation-to-relation properties from the RiC-O 1.0 relation-system rewrite, not "the role an agent played." The clean pattern is the reified one she drew:
- keep the simple shortcut `Event; rico:hasOrHadParticipant→ Person` for easy querying, and, in addition, - reify: `Event; rico:thingIsSourceOfRelation→ EventRelation`, with the EventRelation carrying `rico:relationHasTarget → Person` and the role.
The only missing piece in RiC-O 1.1 is a generic "role played by the agent in this relation" roperty, today there is only `rico:creationWithRole`, scoped to CreationRelation. Florence has confirmed a generic version is intended for RiC-O 1.2. In the meantime we've defined one in our extension namespace:
openricx:relationHasAgentRole (domain rico:Relation, range rico:RoleType) deliberately generic so it works on EventRelation, PerformanceRelation, etc.; not just events, and we declare `rico:creationWithRole` as a sub-property of it so existing creation-role data flows through the same path. When RiC-O 1.2 ships its own property we'll bind ours to it with `owl:equivalentProperty`, so nothing downstream breaks. Turtle for your wedding example:
my-data:JaneDoeWedding a rico:Event ;
rico:hasOrHadParticipant my-data:JaneDoe ; # shortcut
rico:thingIsSourceOfRelation my-data:JDWeddingBrideRel .
my-data:JDWeddingBrideRel a rico:EventRelation ;
rico:relationHasTarget my-data:JaneDoe ;
openricx:relationHasAgentRole my-data:BrideRole .
my-data:BrideRole a rico:RoleType ; rico:name "bride" .
On your instinct to make Role a first-class entity like Position: I'd gently push back. `rico:RoleType` already *is* the reusable, referenceable node (you define "bride" once and point many relations at it), so you get the benefit of a shared vocabulary without a new entity. And Position is genuinely a different thing:
it connects an Agent to a "Group" (an office/post held within an organisation), not an agent to an event, which is why it doesn't fit here.
On adoption / fostering / guardianship, and care homes
RiC-O 1.1 gives you `rico:hasChild`, `rico:hasSibling`, `rico:hasOrHadSpouse` under `rico:hasFamilyAssociationWith`, but nothing for care relationships, so an extension is the way (Florence suggested the same). We've added, in the same extension:
- `openricx:hasAdoptedChild`; sub-property of `rico:hasChild` (an adopted child is a legal child), with inverse `openricx:isOrWasAdoptedChildOf`;
- `openricx:hasFosterChild`; under `rico:hasFamilyAssociationWith` rather than `hasChild`, since a foster child is not legally one's child;
- `openricx:isOrWasGuardianOf` / `openricx:isOrWasUnderGuardianshipOf`; for legal guardianship. Where the guardianship rests on a legal instrument, also relate the two people through a `rico:Mandate` (this is where Mandate earns its keep, the instrument, not the relationship itself).
Where you need the “dates” a relationship ran (fostering 1962–1968, say), reify it as a `rico:FamilyRelation` between the two persons and put the start/end dates on that relation node, same shortcut-plus-reified idea as the role case.
For time spent “in a care-home setting”, I'd actually reach for the role pattern above rather than a kinship property: model the residency (or the episode of care) as an Event/Activity, with the person as a participant playing the role "resident" and the carer playing "carer", each qualified with `openricx:relationHasAgentRole`. Dates then sit naturally on the Event. That keeps a professional/institutional relationship out of the “family”-association hierarchy, where it doesn't really belong, and it ties your two questions together with one mechanism.
Like Position and the guardianship properties, none of this is Position's job, Position is Agent-to-Group only.
If it's useful, the extension ontology (Turtle) and its SHACL shapes are small and open (AGPL); happy to share the files or a link so you can drop them straight into your own graph. And of course, the RiC-AG "how to extend RiC" FAQ Florence linked is the right home base for doing this cleanly.
Groete / Regards,
Johan Pieterse
http://heratio.theahg.co.za/ ·
Ann Attwood
You received this message because you are subscribed to a topic in the Google Groups "Records_in_Contexts_users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/Records_in_Contexts_users/kF-C91bwKfQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to Records_in_Context...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/Records_in_Contexts_users/2c2dd7000e4480bdceddc30f633c35ef%40zandhuis.nl.