ISAD(G) vs RiC-O

[Charlene Ellul]

Dear all,

This is quite a lengthy question and I will try to explain it as best as I can. I am trying to model Notarial documents that have been stored at the Notarial Registers Archive in Malta. The cataloguing process just started in the past 2 years and we have been using ISAD(G), but clearly RiC-O goes beyond and tries to remove unnecessary data. This is the way I am trying to model this archive:

1. Repository: The governing entity is the National Archives: therefore I created the following:

Repository is a subclass of Corporate Body

Fond is a subclass of Record Set

holds is a subproperty of is or was holder or

2. Fond - The Notarial Registers Archive is a Fond within the National Archives:

This is where I don't know if I should keep on following the hierarchy of ISAD(G) or move away from it, since the data is duplicated. Usually a Fond contains a Subfond but what if I link the Fond straight away with the File - avoiding duplication of data? The Subfond usually contains all the records pertaining to a particular Notary but in reality this information can still be extracted if File is linked to the creator as per Option 2.

Option 1:

Option 2: 

3. According to RiC-O hierarchy after the Subfond per Notary, there is the Series ex: Registers of Antonio Abela. This is shown in Option 1. But can't the Series be directly linked to the File straight away. Thus if I have a query stating list all the Registers of Antonio Abela, I can do it using the hasCreator and hasSeriesType Property:

Option 1

Option 2

Of course the diagram continues with an analogue instantiation of a File and SubFiles which also have their analogue instantiations.

I am just uncertain whether I should move away from the hierarchy of ISAD(G) when the modelling using RiC-O will avoid the duplication of data.

Thank you for any insights you will share.

Kind regards,
Charlene

[CLAVAUD Florence]

Dear Charlene,

 

After having had  quick glance at the images you provided, below are my first reactions.

I hope I have understood your question and your specific problem well (also, some images are a bit blurry).

 

 

RiC-O does not prescribe any kind of hierarchical representation like the one you quote (a fonds including a subfonds, including series, each series including files, and files including items). Such a hierarchy is simply one that is possible in the real world of archival resources, and that ISAD(G) enables to express using levels of description. However you do not always have subfonds within fonds, and series (as defined by ISAD(G)) may have subseries which in turn may have sub-sub-series, a file may have subfiles, etc. A fonds may also include a collection. And there are other kinds of record sets than fonds, series, files. So every fonds has its own specific content and internal structure. Besides, in some situations, archivists do not describe items or even files.

 

Rather, what RiC-O says or enables is :

 

• (just like with ISAD(G)) : Represent what really exists in your archival holdings. I am not sure I would consider a notarial fonds of the kind that you are describing have one to many subfonds. If would imply that the subfonds has its own creator and/or accumulator and/or manager. Or, to rephrase it, I am not sure I would consider the Notarial Registers Archive as a Fonds. IMHO the records created by one notary could be considered a fonds (this is at least what we would say in France). But again, I may not have understood everything.

 

• Represent what you need to represent.

If you want/need to connect a record set (whatever it is ; a fonds is simply, from the perspective of RiC, a kind of Record Set ; to be more precise a rico:RecordSet may have a rico:RecordSetType, and ric-rst:Fonds is an instance of rico:RecordSetType) and its direct parts (whatever they are ; they may be subfonds, or series, or even just files,  etc ; or a Record), you can use rico:directlyIncludes. Same for the record set that would be a direct subdivision of the Fonds, and its own direct subdivisions etc. etc. And there, yes you can get exactly what ISAD(G) allows you to do through a classic finding aid – except that the partitive relations are explicit, can be browsed and queried.

If you want/need to represent the fact that some Record or some Record Set (like a file or any group of records) is part of a fonds, but is not (or may not be) direct part of it, the fonds being the largest record set you want to identify, you can use rico:isIncludedInTransitive (or the inverse one, rico:includesTransitive) which would connect this lower level component and the fonds. Note that rico:isIncludedInTransitive, being a superproperty of rico:isDirectlyIncludedIn, can be inferred by OWL reasoners from rico:isDirectlyIncludedIn, so that in such situations you do not need to explicitly state this rico:isIncludedInTransitive. As it is also defined as an OWL transitive property, it can be inferred from a chain of properties or property path that would connect any number of record sets (rico:isDirectlyIncludedIn/rico:isDirectlyIncludedIn/rico:isDirectlyIncludedIn, etc.This property may help you query your graph later, or display information which concerns the fonds when you display the description of this lower level archival resource.

On this topic, see also https://ica-egad.github.io/RiC-O/migrating-data-from-RIC-O-v0.2-to-v1.0.html#changes-made-to-the-core-object-properties.

• Add specific properties when needed ; for example, you could create a property to say that a Record Set or File (or anything you need to describe this way) is included in some Fonds. This should IMHO probably be a subproperty of rico:isIncludedInTransitive.

 

There would be much more to say (including about addressing the cases where a record resource is involved in more than one aggregation simultaneously) about representing aggregations of record sets, or sequences of record sets.  We also have added to RiC-O 1.1 datatype properties to store the rank of a record resoiurce in a hierarchy (rico:rankInHierarchy). To be used carefully (ideally, to be filled automatically).

 

As concerns rico:hasCreator, if it is true that the files or series have the same creator as the fonds (it is usually the case in most of notarial records, but it is more generally speaking not at all always the case in the archival world) you could even propagate, through reasoning, this property, from the fonds that is connected to the creator using rico :hasCreator, to the members of this fonds.

 

Again, I may not have understood everything from what you said or shown.

Maybe we could continue this very specifif discussion outside this list 😉.

 

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
Envoyé : vendredi 18 juillet 2025 08:32
À : Records_in_Contexts_users <records_in_c...@googlegroups.com>
Objet : [Records in Contexts users] ISAD(G) vs RiC-O

 

Dear all,

 

This is quite a lengthy question and I will try to explain it as best as I can. I am trying to model Notarial documents that have been stored at the Notarial Registers Archive in Malta. The cataloguing process just started in the past 2 years and we have been using ISAD(G), but clearly RiC-O goes beyond and tries to remove unnecessary data. This is the way I am trying to model this archive:

 

1. Repository: The governing entity is the National Archives: therefore I created the following:

Repository is a subclass of Corporate Body

Fond is a subclass of Record Set

holds is a subproperty of is or was holder or

 

2. Fond - The Notarial Registers Archive is a Fond within the National Archives:

 

This is where I don't know if I should keep on following the hierarchy of ISAD(G) or move away from it, since the data is duplicated. Usually a Fond contains a Subfond but what if I link the Fond straight away with the File - avoiding duplication of data? The Subfond usually contains all the records pertaining to a particular Notary but in reality this information can still be extracted if File is linked to the creator as per Option 2.

Option 1:

Option 2: 

3. According to RiC-O hierarchy after the Subfond per Notary, there is the Series ex: Registers of Antonio Abela. This is shown in Option 1. But can't the Series be directly linked to the File straight away. Thus if I have a query stating list all the Registers of Antonio Abela, I can do it using the hasCreator and hasSeriesType Property:

Option 1

Option 2

Of course the diagram continues with an analogue instantiation of a File and SubFiles which also have their analogue instantiations.

 

I am just uncertain whether I should move away from the hierarchy of ISAD(G) when the modelling using RiC-O will avoid the duplication of data.

 

Thank you for any insights you will share.

 

Kind regards,
Charlene

--
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/731d17a0-9e42-46b4-9c15-44d47c2bf6d9n%40googlegroups.com.

---

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

[Richard Williamson]

Dear Charlene,

Just a few complements to Florence's feedback, in case they are helpful! Thank you for raising this interesting question, I am as ever impressed with your modelling! If I understand correctly, the heart of your question is the following: can we 'skip levels in the ISAD(G) hierarchy' when modelling in RiC, for instance can we say that a File belongs to a Fonds, leaving Series And Subfonds only implicit? This is something I think again lots of people will be interested in, so great that you ask it! 

For me I think there are a few different aspects to an answer to your question:

1) Technically, the answer is definitely yes, as Florence wrote: one can include any Record (or Record Set) into any type of Record Set (Florence explained in detail that 'directly includes' might not be appropriate, but 'transitively included', etc, can be used), and it is definitely then possible to use a SPARQL query to obtain 'all register of a particular notary' and similar.

2) A major consideration would I think be whether the record sets 'all registers of a particular notary' and so on are purely intellectual aggregations, or whether they actually have instantiations, i.e. the instantiations of the files are held together physically in some meaningful archival sense (analogue or digital), and there is metadata relating to the instantiation that one wishes to include. If the latter is the case, then one might wish to have the record sets included in the modelling, not only have them be implicit. If there is only interesting metadata to do with the instantiation, though, it is perfectly valid OWL to leave the Record Set from which an Instantiation comes implicit, and just use 'has or had component' at the instantiation level to relate the instantiation of the (implicit) series to an instantiation of a file in it. 

If the record sets are purely intellectual, then the question as to whether to include them probably comes down to whether they serve any useful purpose. If they are merely bureaucratic book-keeping (a system demands that something is filled in there), then it would seem a good idea to omit them if one can if one has a new system without such constraints! If there is intellectual (not pertaining to instantiation) metadata that one wishes to enter that is specific to them, then of course one should include them.

3) I think your idea of using 'series type' rather than actual series is an intriguing one! I definitely see that this will save space in the kind of situation you envision, i.e. instead of introducing a series for 'private registers of X' for each X, we just have a single 'private registers of a notary' type, and say that individual registers of X all have this type; again, it is definitely true that one could reconstruct the 'series' using a SPARQL query then. (I guess that SeriesType in your modelling here would be a subclass of rico:RecordSetType, and 'hasSeriesType' would be a sub-property of 'hasOrHadType'). This is a bit 'non-canonical' RiC at the moment, but if more people prefer doing this than introducing Series directly (caveat my point 2) above: if one takes this approach, it must then be the case the only interesting intellectual aspect of the series is in defining a certain 'grouping' that can people can e.g. search for, without any need to attach further metadata to the Series; but I do see that this might well often be the case), it could be something could be considered for addition in RiC-O in the future.

Other than 1) - 3), I just wished to remark in case others were wondering that one can just use 'hasRecordSetType ric-rst:Fonds' to say that a Record Set is a Fonds, one does not have to introduce a sub-class as you do, but of course the latter is a perfectly valid modelling technique, and one could assert that such a sub-class is equivalent to the restriction class 'hasRecordSetType exactly ric-rst:Fonds' to allow for inter-operability with people using the other technique.  

I also wished to note that just by using RiC-O, one almost certainly takes large steps in the direction of cutting down data compared to a relational database approach. For a simple example, in a relational database, for every register of Antonio Abela, one might well have a row with an entry in the 'creator' column which states 'Antonio Abela'. From a graphical point of view, one can think of this as two nodes for each register connected by a 'creator' arrow (making 'Antonio Abela' into a new node each time). Whereas in RiC-O there will be a single 'Antonio Abela' node to which all the register nodes have an arrow. One might argue: but in a relational database, we could make a table of agents, and just have an id pointing to it in the register table, is that not the same thing? Maybe, maybe not (one has a problem if more than creator is allowed, for instance), but even if one escapes the issue there, and tries to escape it for all other columns similarly (which would be a nightmare syntactically for constructing SQL queries), one will run into a superfluity (junction tables, etc) at some point which RiC-O does not have, e.g. if one has a need to relate agents to one another.

Hope there was something useful there!

Best wishes,

Richard

--