Authorities - Person

[Charlene Ellul]

Hi,

After a long pause, I resumed the work using RiC-O. I am currently concentrating my efforts to model a Person who worked as a Notary. Our collection (the Notarial Registers Archive) contains documents that have been produced by individuals who worked as Notaries.

Therefore I have tried to model the following details:

1. Name variations. I have decided that PersonFirstName and PersonLastName should be seperate classes; both subclasses of AgentName. This way I can have variations of the same firstname and lastname once and use them to construct the full name of the person. This will also allow maiden names to be included for female notaries. 
2. Person will have its label as per Government Gazette - which is the official name recognised by the Government (not necessarily the Notary's true name - in most cases it would be changed to a current spelling)
3. Each Person is given an identifier - this is the Authority identifier
4. I have modelled the possibility for a Person to hold 2 "Occupations":
   1. Private Practice - modelled as NotarialTenure (subclass of Activity) with the beginningDate, endDate and linked to the Places he practised in. The identifier is the warrant number associated with the private practice.
   2. Notary To Government - Some notaries also held the position of a Notary To Government (optional). This position was held by different notaries along the years. A notary might had a private practice or not.

I would appreciate your feedback on the modelling done. 

[Richard Williamson]

Dear Charlene, 

Great to hear that you're resuming work with RiC, and thank you very much for sharing the modelling! Several intriguing things to reflect upon here! In short, I think your modelling looks excellent, and I have no criticisms, only a couple of quick additional reflections/suggestions:

1. Probably you already thought of it, but it could be good to connect your 'first name' and 'last name' properties for instance to some ontology, for example to FOAF. Here is one relevant entry there.

http://xmlns.com/foaf/spec/#term_familyName

Ideal I think would be if one had an ontology specific to naming of people which goes a little further than FOAF, definitely including maiden name for example, but I'm not sure there exists something in widespread use.

2. A very minor point, but I think I would probably use rico:textualValue rather than rico:name for the textual forms of the names (michele, michaeles, and so on).

3. Again, you have probably already thought of it, but it could be nice to include within the modelling the kind of thing that you expressed in your post to your list: about the fact that the names might be spelt differently in an official context, or be maiden names, etc. There are different ways to do this, but the simplest could be just to include a rico:note, and/or to make custom sub-datatype properties of rico:textualValue (cf. my point 2.); if taking the latter approach, one could include some meta-metadata about the new datatype properties at the level of RDF using 'reification' (or likely better if you have the software to use it: RDF-star).

4.I think it could be useful at least from the point of view of interoperability, and probably too for applications built upon the modelling, to include the full textual forms of the names as well, not only their parts. E.g. due to cultural differences, it might not be obvious to everyone how to combine first name and surname (which one comes first, etc). This would probably work well if combined with the kind of considerations in 3. If within your own datasets you always use first name and surname in a way which can be combined to a full name in the same way, you could consider using a SHACL rule to generate the full names, i.e. you could distinguish between two datasets, one which you use to enter the data, and one for publishing where you run some SHACL rules, etc beforehand.

5. Another trivial point: since it is an Activity, you could also connect NotarialTenure to the 'notary' occupation type using 'hasActivityType'. 

Hope there was something a little useful/thought-provoking there :-). Thank you again for sharing this, many people will have a need to express this kind of thing!

Best wishes,

Richard

--
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/9b0b1780-c067-4a98-9a90-a8060d48b1b1n%40googlegroups.com.

[CLAVAUD Florence]

Dear Charlene,

It's good to know you are resuming this interesting work!

As concerns the model you describe and the diagram attached, here are my own firsrt thoughts in addition to Richard's comments:

1. name variations

It sounds good. You could also SKOS properties (in addition to rico:name or - better-  to rico:textualValue, as Richard already said), e.g. skos:prefLabel or skos:altLabel, if needed, to distinguish e.g. the preferred form of the first or last name (see https://www.w3.org/TR/skos-reference/#labels). Of course you can (you should, as obviously you have names in various languages including Latin) also specify the language used for each value of these properties.

If you need so, RiC-O also provides rico:usedFromDate and rico:usedToDate datatype properties (and rico:wasUsedFromDate and rico:wasUsedTodate object properties), with domain rico:Appellation (superclass of rico:AgentName). And nothing prevents you from extending RiC-O there, and adding a property like 'isMentionedIn', to connect e.g. an instance of PersonLastName and a rico:RecordResource that mentions this last name.

The only possible issue I can see with this model is that you do not store the full name as an entity (which would imply that you introduce another class for this full name, and use properties like rico:hasOrHadPart to connect an instance of the full name to the last name and first name). Maybe you do not need this, and it is not an issue for you; you may even not want to do this, as it may introduce some additional and not helpful complexity. Anyway you can also directly assign a rico:name (full name) (and/or rdfs:label, skos:prefLabel and any other SKOS property) to each notary, which would provide you with an easy solution whenever you have to display the description of the notary.

3. authority identifier.

This sounds good too. You could also use a class to manage identifiers (rico:Identifier) but it may not be useful, particularly if these identifiers do not need to be described, do not change, etc.

4. "occupations"

As concerns the private practice, unless I have not understood it well, you mean that a (or one to many) NotarialTenure is defined for each notary? if so, the model seems good, and it can be considered a subclass of rico:Activity, that would have its own dates. It enables you, among other possibilities, to assert that some NotarialTenure is documented by (rico:documentedBy) one to many record sets. 

If such an activity changes location through time, IMHO it could be appropriate to consider using an intermediate node between the Activity and each of the rico:Place(s) concerned, in order to assign dates and/or a description to it, since these dates are not the dates of existence of the place nor of the activity. This node could be an instance of the rico:PlaceRelation. This would mean that the activity was located from some date to some date in some Place(s), then during some other date range in another place(s), etc.

Another option would be to use rico:Person (for the notary), one to many rico:PerformanceRelation (a node between the person and the activity), the NotarialTenure class, and to connect each of the rico:PerformanceRelation, in addition to the NotarialTenure, to rico:Place(s) and to rico:Date(s). Thus in such a model both the dates and places would concern the relation. The activity could also become something more abstract, performed by many notaries through time - this, of course only if it can be described as such and if such a description is useful for the project. Which is not certain at all. Basically it depends on how you view the activity!

As concerns the NotaryToGovernment position, as you describe it, the model seems good too. Theoretically speaking, it would imply that you describe the 'Government' entity (probably as a rico:CorporateBody), but you can also just describe what you know and need.

As the position has its own existence and dates, which are not the same as the dates when some notary occupied the position, just like for the NotarialTenure class, you could consider using an intermediate rico:positionHoldingRelation between the person and the position, to say that some notary occupied some position from some date to some date.

Finally, you could also, of course, create a Notary class, subclass of rico:Person (and assert for example that a notary is a person who has occupation type notary). This may help you manage and query, in a possibly big dataset, the descriptions of notaries, particularly if you plan to describe other persons in the dataset (like the notaries' clients, the witnesses to the notarial deeds, etc.). At the AnF, this is what we did for managing the notaries in the dataset published within our prototype for metadata on  records produced by the Parisian notaries (see the documentation here: https://sparna-git.github.io/sparnatural-demonstrateur-an/presentation-en.html; and this file: https://github.com/ArchivesNationalesFR/Sparnatural_prototype_data/blob/52c6c4e58338fc31b8569a739bd5a5f4dfa25d4f/RDF/sparql_updates/Sparql_insert_operations.txt.)

Hope this helps!

Best regards, 

Florence

--

Florence Clavaud
Executive member of ICA/EGAD ; lead of RiC-O development team
Conservatrice générale du patrimoine | General curator
Responsable du Lab des Archives nationales de France| head of the Lab, Archives nationales de France

---

De : records_in_c...@googlegroups.com <records_in_c...@googlegroups.com> de la part de Charlene Ellul <charlen...@nafmalta.org>
Envoyé : mercredi 25 juin 2025 00:31
À : Records_in_Contexts_users <records_in_c...@googlegroups.com>
Objet : [Records in Contexts users] Authorities - Person

 

--
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/9b0b1780-c067-4a98-9a90-a8060d48b1b1n%40googlegroups.com.

---

Merci de nous aider à préserver l'environnement en n'imprimant ce courriel et les documents joints que si nécessaire.

[Charlene Ellul]

Dear Richard and Florence,

Thank you for your feedback. It is always important to bounce off ideas with others. Many thanks once again.

Kind regards,

Charlene