About ICA Records in Contexts Ontology (RiC-O)

An information website about Records in Contexts Ontology (RiC-O).

View the Project on GitHub ICA-EGAD/RiC-O

Migrating data from RiC-O 0.2 to RiC-O 1.1

Last updated on 2025, May 23rd

Though the following information and recommendations do not pretend to be exhaustive, we hope that they can help the teams which have already produced datasets conforming to RiC-O (thus to RiC-0 0.2 or RiC-O 1.0) to make them compliant with RiC-O 1.1.

RiC-O 1.0, which is the first stable and complete version of RiC ontology, and thus a major milestone in the development of the standard, then RiC-0 1.1, introduced some new components; they also brought some changes on the specifications of the v0.2 components: the qualified names, definitions, domains or ranges of some have changed. Besides, some components have been removed. In other words, RiC-O 1.0 and therefore RiC-O 1.1, are not, as a whole, compatible with RiC-O 0.2. This is why, if you have been using RiC-O 0.2 and want to move to RiC-O 1.1 (which we would recommend you choose), you may need to modify your data.

We will mainly focus on the most significant changes made to RiC-O 0.2 components, that imply that you need to check and update your existing RiC-O datasets accordingly and update them when necessary. We will start with the changes that concern the core of RiC-O (i.e. everything but the Relation classes and their properties). We will also emphasize some of the additions made that may be in our opinion quite often useful.

Remember that each release of a new official version of the ontology comes with an exhaustive list of changes made since the previous official version. You can therefore find there all the useful additions to the information given below.

Before modifying your data, in order to get a more precise understanding of what has to be done in your dataset, you could, in addition to reading this text and the release notes:

In the following lines, we use the rico prefix for RiC-O 1.1 components only. When we do not specify what version of RiC-O includes the changes listed, we mean that it is RiC-O 1.0.

Changes affecting the core of RiC-O

A new model for Dates

Though this is the main change, it will affect your data only if you have instantiated the Date classes. In many projects, dates are expressed using RiC-O datatype properties, where almost nothing has changed.

The three v0.2 subclasses of the rico:Date class (DateSet, DateRange and SingleDate) have been removed. As a consequence, any instance of these classes should be modified and declared as being of type rico:Date.

In addition to these changes:

Changes made to other ‘core’ classes

A rico:MandateType class was created, as a subclass of rico:RuleType, along with the two object properties needed to connect instances of this class to instances of rico:Mandate.

In RiC-O 1.1, a rico:TitleType class was created, as a subclass of rico:Type, along with the object properties needed to connect instances of this class to instances of rico:Title.

Changes made to the ‘core’ datatype properties

In addition to the datatype properties whose domain is rico:Date and which are quoted above, you should pay attention to the following changes:

A new rico:destructionDate property was also created, subproperty of rico:endDate. Note that while this property had domain rico:Thing in RiC-O 1.0, its domain has been restricted to the union of rico:RecordResource and rico:Instantiation in RiC-O 1.1.

Let us also mention that in RiC-0 1.1, nine datatype properties, with domain rico:RecordResource or its subclasses, and/or rico:Instantiation, were also added, to provide users with more precise relations for storing dates (e.g. rico:migrationDate, rico:derivationDate or rico:accumulationDate).

You may be interested in using the rico:note datatype property, which was added to RiC-O 1.1, and made a superproperty of the already existing, more specific, note datatype properties (rico:physicalCharacteristicsNote, rico:authentiticyNote and rico:integrityNote). This generic property can be used whenever you need to store a short textual statement, that gives a little information on a specific feature of a rico:Thing; it can also be extended to address other specific needs.

You will also find in RiC-O 1.1 a new rico:recordResourceSourceOfInformation datatype property (as well as the rico:recordResourceHasSourceOfInformation object property alternative solution, and its inverse) to store information about the source on which a rico:RecordResource is based. This can be used e.g. for specifying a source (e.g. a Wikipedia page, an article or book) on which the content of an authority record is based (like the source element in the XML/EAC-CPF schema.)

Finally, if you need some practical solution to help you display or query a graph showing a sequence or hierarchy of record resources (and/or of instances of rico:Proxy representing record resources), you can now find in RiC-O 1.1 two datatype properties, rico:rankInSequence and rico:rankInHierarchy to be used in addition with the object properties that constitute such a sequence or hierarchy.

Changes made to the ‘core’ object properties

The following changes have been made:

In RiC-O 1.0.1, the IRI of rico:hasOrHadSomeMembersWithDocumentaryFormType was corrected (‘with’ replaced by ‘With’).

In RiC-O 1.1, rico:hasOrHadCategory was replaced with rico:hasOrHadType (and the inverse object property, isOrWascategoryOf, was replaced with rico:isOrWasTypeOf.)

In addition to these changes, many object properties have been added, which may help to produce more precise data, or data which would be easier to process. The inverse properties were also created, though we most often are not mentioning them below. The following is a non-exhaustive list of these additions:

Object properties have been created under the following existing properties, in order to distinguish past and present relations, and, as concerns present relations, to get transitive properties:

For example, rico:directlyIncludes can now be used to connect a Record Set and its direct present members, and rico:includesTransitive can be inferred from this, or created, to connect a Record Set and its present, direct or indirect, members (e.g. a fonds and an item in this fonds). This can be applied when you want to generate data from a tree of EAD c elements. Rico:included can be used to connect a Record Set and a former member of this Record Set.

The image below shows the hierarchy of properties under rico:includesOrIncluded, as displayed by Protégé Desktop.

images/hasOrPart_hierarchyOfProperties.png

Rico:directlyFollowsInSequence can now be used to connect a Record Resource and its direct following sibling in a sequence of Record Resources. Rico:followsInSequenceTransitive can be inferred from this property, or created, to connect a Record Resource and any of its following siblings in a sequence. This can be applied when you want to generate data from a sequence of EAD c elements. On this topic see also issue 41, and issue 97.

in RiC-O 1.1, new properties, some of which being transitive, were added in order to complete the model as concerns the representation of sequences and hierarchies of record resources. In particular, this resulted in a significant set of object properties in order to allow the use of rico:Proxy in such sequences and hierarchies. On this topic, see also issue 97 and pull request #136.

Last but not least, two properties (rico:hasContentWhichRepresents and rico:hasContentWhichMainlyRepresents) were added as subproperties of rico:hasOrHadSubject and rico:hasOrHadMainSubject, in order to connect Records or Record Parts and the Things they represent. Variants of those properties were created in order to connect a Record Set and the Things that some or all of its members are about or represent. The inverse properties were also created. You could consider using these properties for describing any visual items.

Changes made to the system of Relation classes

The AgentOriginationRelation was replaced with rico:OrganicProvenanceRelation, subclass of a new rico:OrganicOrFunctionalProvenanceRelation class.

The source datatype property was replaced with rico:relationSource datatype property, with domain rico:Relation. Same for the certainty datatype property, which was replaced with rico:relationCertainty. As already said above, the hasSource object property, whose domain included rico:Relation and whose range was the union of rico:Agent and rico:RecordResource, was replaced with a rico:isEvidencedBy object property, with domain rico:Relation only and range rico:RecordResource. Same for the inverse property, isSourceOf, which became rico:evidences.

In RiC-O 1.1 a new n-ary relation class, rico:StudyAtRelation, was created, subclass of rico:MembershipRelation. The new rico:studiesOrStudiedAt object property and its inverse property were declared shortcuts of the more complex path involving instances of this new class.

Also, note that a new rico:relationHasDate object property was created in RiC-O 1.1, with domain rico:Relation. Therefore new chain property axioms could be specified, using this new property, for connecting Record Resources or Instantiations to a Date, through the n-ary provenance Relation classes (rico:OrganicProvenanceRelation, rico:CreationRelation and rico:AccumulationRelation) and the Instantiation to Instantiation relations (rico:DerivationRelation and rico:MigrationRelation). These axioms were added to the specification of the new object properties also created recently and listed above, like rico:hasOrganicProvenanceDate or rico:hasMigrationDate. The new rico:isOrWasActiveAtDate property was also declared as a shortcut for rico:thingIsTargetOfRelation o rico:performanceRelation_role o rico:relationHasDate.

The Relation classes have been rolified, for the reasons, and following the method and pattern, explained here.

As a consequence:

Again, you can read much more details about this on the page related to issue 67.

Here is an example of what has changed, for a rico:LeadershipRelation.

Figure 1 shows how this relation is expressed using RiC-O 0.2.

images/a-complex-relation-and-its-shortcut_inRiC-O_0.2.png

Figure 2 shows how the same relation is now expressed using RiC-O 1.0 or later versions.

images/a-complex-relation-and-its-shortcut_inRiC-O_1.0.2.png

The image below shows the RDF/XML data that corresponds to Figure 2.

images/rico_LeadershipRelation.png

The rico:LeadershipRelation itself is now defined as follows (see the ontology file or HTML page to get the full specification):

images/rico_LeadershipRelation.png

Warning

Suppose you want to be able, in your dataset, to use the property path quoted in the caption of Figure 2 above (rico:thingIsSourceOfRelation/rico:leadershipRelation_role/rico:relationHasTarget), and any similar property path involving some *_role property, directly in SPARQL queries, in order to traverse the relations you have instantiated.

Most of graph databases do not support for now the OWL 2 owl:hasSelf declaration that is included in the definition or the Relation classes. So they cannot infer the triple that uses the *_role property and connects the instance of the Relation class to itself, from the assertion that the instance is a Relation (for example, if you assert that an entity is a rico:LeadershipRelation, the graph database you use will most probably not be able to infer the triple that connects this instance of the rico:LeadershipRelation to itself using rico:leadershipRelation_role).

So, in order to be able to use such property paths, you should, as said in a comment of the RDF/XML example above, either also generate the triple that connects each instance of a Relation to itself in your RiC-O 1-0 dataset, before importing it into the graph database, or add it to the dataset, once imported, using for example SPARQL Update.

Also, note that, once such property paths exist in your dataset, the shortcut triples like the two ones shown in the RDF/XML example above will be inferred automatically from the property chain axioms declared in RiC-O 1.0 by a OWL-RL reasoner. However, if your graph database is not configured to use such a reasoner and if you wish to use the shortcuts to query the data, you should also generate at least one of these two shortcut triples, either before or after importing the data in your graph base.