rico: RDF Prefix

International Council on Archives Records in Contexts Ontology (ICA RiC-O) version 1.0.2

Introduction RiC-O (Records in Contexts-Ontology) is an OWL ontology for describing archival record resources. As the third part of Records in Contexts standard, it is a formal representation of Records in Contexts Conceptual Model (RiC-CM). This version, which is v1.0.2, is the latest official release. It is compliant with RiC-CM v1.0. The following diagram shows the main RiC-CM 1.0 entities and a few relations between them: RiC-O design principles The following design principles were followed when developing RiC-O. 1. RiC-O is a domain and reference ontology. RiC-O provides a generic vocabulary and formal rules for creating RDF datasets (or generating them from existing archival metadata) that describe in a consistent way any kind of archival record resource. It supports publishing RDF datasets as Linked Data, querying them using SPARQL, and making inferences using the logic of the ontology. While some projects have built some specific ontologies for describing archives, in 2013 no generic domain ontology existed for the specific needs of the archival community. This is why EGAD decided to develop RiC-O as a part of RiC standard. Apart from this first, main target, RiC-O, as a technical implementation of RiC-CM that also extends and refines it and that includes formal logic, can guide or inspire, in many ways, the development of any tool or system that manages (i.e. stores, enables to edit or processes) and publishes descriptive archival metadata.. Of course, other technical implementations of RiC-CM may be developed later on. Also, the current technical implementations of the former ICA standards, e.g. EAD and EAC-CPF XML schemas, should be made closer to RiC-CM in the future; on this topic, see the news and announcements of the Technical Subcommittee on Encoded Archival Standards (TS-EAS) of the Society of American Archivists. As RiC-O is a generic, domain ontology, it does not address by itself every specific need or expectation that may occur in every archival institution or project. It is rather a high level framework and an institution or project implementing RiC-O can apply only such a subset of properties as meets their needs, or extend the specification according to their particular requirements, or do both. As a domain ontology, RiC-O, at this stage, does not borrow from other existing ontologies (such as the cultural heritage models – IFLA-LRM and CIDOC-CRM, PREMIS, or PROV-O). It should therefore be easier, for an archival institution or archival project, to understand, implement and maintain RiC-O within its system. Alignment with those and other models, where possible, will be undertaken in a future revision cycle to support the interconnected nature of resource description across the domains. This is of course essential for interconnecting RDF datasets conforming to RiC-O with other datasets, or for using parts of RiC-O in other contexts than the archival or records management realm. 2. RiC-O is immediately usable. This is a key feature. Metadata conforming to superseded ICA standards can be transformed to RiC-O successfully. Converting existing archival metadata created or generated in current information systems and compliant with ICA standards to RDF/RiC-O is possible without losing data or structure. During the ongoing development process of RiC-O, intensive conversion testing, either by hand or using scripts, was conducted on XML/EAD finding aids and XML/EAC-CPF authority records to ensure that RiC-O is usable with existing descriptive metadata. An open source conversion software was also developed and made available in April 2020. While some existing metadata sets may have a very fine level of granularity and accuracy, already using, for example, controlled vocabularies, or describing curation events separately, often these metadata don’t have the very precise structure that RiC-CM recommends. Even then, such a conversion process remains possible. In order to allow this, RiC-O sometimes provides several methods for representing information (as described below). From this point of view, RiC-O v1.0 may be considered a transitional ontology, in which some components may be deprecated later on. The usability of a model also depends on its documentation. RiC-O is documented extensively. The documentation will be reviewed and updated on a continuing basis. 3. RiC-O provides a flexible framework. This is a very important principle too. It is related with the usability principle quoted above. Moreover, archival description is flexible by essence. It is quite commonly noted that today the level of granularity of information varies from one finding aid to another (or from one authority record to another), or even within the same finding aid. Some series or agents are described summarily because little is known about them and there is little time for extensive research, while other series, even records, or agents are described in detail; some relations (e.g. that relating to provenance) may be described without any detail while others may be thoroughly documented, as ISAAR(CPF) and EAC-CPF allow it. Being generally flexible, for an OWL ontology, depends first on the polyhierarchical systems of classes and properties it provides. A superproperty or superclass, more general or generic than its subproperties or subclasses, must exist and be available for handling information, while at the same time more accurate subcomponents must be there for handling more accurate description. Also, RiC-O provides methods for describing relations as full entities, as well as direct and short paths between entities. 4. RiC-O opens new potential for archival description. Linked Data tools and interfaces enable end users to go through RDF/RiC-O graphs, query them using SPARQL, and make inferences. This means a completely new way of consulting archival metadata and their multiple contexts. An end user should be able to ask of any given data set, for example, “What are (according to your dataset) the corporate bodies that succeeded a given entity from its end of existence to now (as concerns this given activity)?”, or “what instantiations of this photograph exist?”, or “what are the existing copies of this original charter?”, and get a list of these entities. This means that institutions or projects that invest in the implementation of RiC-O will be able to query their data in ways not possible with the previous ICA standards, and will get new insight into the content and context of their archives that wasn’t visible with the existing ICA-standards. What is more, repositories using RiC-O may infer new assertions from the RDF datasets and link them to other resources outside their institution, thereby amplifying the query and inferencing possibilities manifold. 5. RiC-O is extensible. Institutions with descriptive needs beyond what RiC-O provides out-of-the-box have the option of extending the ontology by adding new subclasses or subproperties as needed. Also, the concepts defined in existing SKOS vocabularies (e.g. a list of documentary form types) can also be connected to RiC-O based graphs (using the *Type classes, and properties which are in the domain or range of these classes). RiC-O has also the potential to be usable in other contexts than purely archival ones. It can be used to “hook” archival description to descriptive metadata in other domains (e.g. bibliographic or museum metadata). As said above, alignment with other models will be undertaken by EGAD in a future revision cycle, facilitating such connections. Understanding RiC-O: a quick overview of some features From RiC-CM to RiC-O 1. From RiC-CM components to RiC-O classes Each RiC-CM entity has a corresponding class in RiC-O. These classes are organized according to the same hierarchy as in RiC-CM. Some projects may need very few of them (e.g. Agent, Record Resource and Activity only), while others may need more (e.g. Corporate Body and Person; Record; Place; Organic Provenance Relation). Many classes only exist in RiC-O and not in RiC-CM. These additional classes address special needs: some correspond to RiC-CM attributes, when it may be considered necessary to handle them as full entities. This is the case for Type and its subclasses, that correspond to RiC-CM attributes that contain controlled values, and that can help to articulate RiC-O with external RDF resources like SKOS vocabularies; and also for Language, Name and Identifier, that can be considered as full entities and as key linking nodes in a RDF graph. All these classes have been grouped under a Concept class. some classes have been added in order to provide a more accurate definition and model for some entities. Place thus comes along with a Physical Location class, and with a Coordinates class. A Place is considered both a geographical and historical entity. As a historical entity, among other features, it has a history, and may be preceded or succeeded by other Places. A Place also may have zero to many Physical Location through time (for instance, its boundaries, if it is an administrative area or a country, may change). Each Physical Location may be connected to zero to many Coordinates. This model is quite close to the Linked Places Format (https://github.com/LinkedPasts/linked-places). Another example of such an addition is the Proxy class, that represents (stands for) a Record Resource as it exists in a specific Record Set. finally, a system of n-ary classes helps to implement the Relations section of RiC-CM. While these relations also are represented as simple, binary object properties (e.g. hasOrganicProvenance that corresponds to RiC-R026 relation), you may need to assign different attributes to a relation, e.g. a date, certainty or description, as it is already possible, and quite often done, in a XML/EAC-CPF file. One of the standard available methods for representing such a documented relation in RDF for now is to use a class. The RDF-star specification, which is being developed by the W3C RDF-DEV Community Group, provides a far simpler method (allowing to consider a triple as the subject or object of another triple; see https://w3c.github.io/rdf-star/) and is already being used by some tools; however it is not yet a complete W3C standard. Thus, for example, in RiC-O a OrganicProvenanceRelation class exists. This class may connect one to many Agents to one to many created or accumulated Record Resources or Instantiations, and has some specific object properties (certainty, date, description, source). Back to the hasOrganicProvenance object property, let us add that it is formally defined in RiC-O, using OWL 2 property chain axiom (see https://www.w3.org/TR/owl2-new-features/#F8:_Property_Chain_Inclusion), as a ‘shortcut’ for the longer path ‘thingIsSourceOfRelation/organicProvenanceRelation_role/relationHasTarget’, where the intermediate node is an instance of OrganicProvenanceRelation: A triplestore, with the appropriate configuration, may thus infer the direct ‘hasOrganicProvenance’ assertion from this long path. 2. About RiC-O datatype properties (relations whose object is a litteral) Most of the datatype properties in RiC-O correspond to RiC-CM attributes that contain free, plain text. See for example rico:generalDescription, rico:history and rico:scopeAndContent. In many simple usecases it’s sufficent to just use the rico:identifier or rico:name datatype properties. However, in addition to these datatype properties, the Name and Identifier RiC-CM attributes also have corresponding classes (subclasses of rico:Appellation). A resource may have several Identifiers (e.g. archival reference code, system number, digital object identifier) or Names and each comes with different attributes; in this case instances of classes are needed. The Location RiC-CM attribute also has a rico:PhysicalLocation corresponding class (for users who want to use Place, Physical Location and Coordinates for handling places). As already said too, every RiC-CM attribute that has ‘controlled value’ or ‘rule-based’ as a schema value, has a class as corresponding component in RiC-O. However, for these CM attributes that correspond to a RiC-O class, as it is necessary to provide an immediately usable ontology, two supplementary datatype properties exist that allow not to use the classes, at least for a while, if you want to implement RiC-O and create RiC-O/RDF datasets from existing archival metadata without being able to handle URIs for the information you have. For example, you may not be able to handle and maintain URIs for some controlled values you use in EAD finding aids for carrier types: maybe your information system does not use a vocabulary for this, and you cannot for a while consider these carrier types as full entities. Nevertheless you want to produce RiC-O datasets where every piece of information is kept, and you want to avoid blank nodes. If RiC-O would only provide the Carrier Type class, it would be an issue for you. So RiC-O provides a rico:type datatype property, with range rdfs:literal, which allows you to move forward. For RiC-CM Coordinates attribute, you also have the rico:geographicalCoordinates datatype property. These datatype properties have a skos:scopeNote which says (for example) "Provided for usability reasons. May be made deprecated or removed later on. Use only if you don’t use Physical Location and Coordinates classes with Place." The same key design principle (RiC-O must be immediately usable) led us to define some datatype properties that would enable users to use RiC-O in simple usecases where they do not want to consider dates and rules as full entities. Thus, there of course is Date and Rule classes in RiC-O (since there are Date and Rule entities in RiC-CM). And you also have a rico:date datatype property, which has several subproperties; plus a rico:ruleFollowed datatype property. The same analysis led us to keep the rico:history datatype property in RiC-O (same as RiC-CM history attribute), while RiC-CM and RiC-O also provide the Event class, and using a series of Events may of course be a better method, easier to query, link and display, than simply using a history prose discourse. The two methods may be used in parallel within the same dataset by an institution that, for example, would decide to emphasize only the accession, appraisal and description events among the whole history of Record Resources. These datatype properties have the same kind of skos:scopeNote as above. Finally, we have introduced a few datatype properties that do not correspond to any RiC-CM attribute. Some are superproperties, and thus group datatype properties: rico:physicalOrLogicalExtent, with rico:carrierExtent, rico:instantiationExtent and rico:recordResourceExtent as subproperties; rico:textualValue, with rico:expressedDate, rico:normalizedValue and rico:quantity as subproperties; rico:measure; rico:referenceSystem. Some are simply more specific properties: rico:accrualsStatus; rico:recordResourceStructure and rico:instantiationStructure, subproperties of rico:structure; rico:title (subproperty of rico:name); rico:altitude, rico:height, rico:latitude, rico:length, rico:longitude, rico:width (subproperties of rico:measure), rico:geodesicSystem and rico:altimetricSystem (subproperties of rico:referenceSystem). 3. About RiC-O object properties (relations between two entities) In order to connect all the classes created, a significant number of object properties have been defined, in addition to the 85 relations defined in RiC-CM 1.0. While the 'flat' list of object properties is a long one, the object properties are grouped hierarchically, so that one can use the upper to intermediate level ones for simplicity sake, or choose the most accurate and expressive ones, or extend the system adding a subproperty easily. It is expected that, in most use cases, a subset of these properties only will be needed. Below we just give a few details on certain specific sets of properties. While in RiC-CM it was not possible to achieve such a level of precision with simple attributes, RiC-O includes object properties to assert that a rico:RecordSet has or had members (either all of them, or some of them) that share some characteristics, i.e. Language, ContentType, DocumentaryFormType, LegalStatus, or RecordState. See for example rico:hasOrHadAllMembersWithCategory, and its subproperties. Some of the object properties are formally defined as shortcuts: they can be inferred if you create triples that include instances of the Relation classes. See the example explained above in the section dedicated to classes. Many properties, new in RiC-O 1.0, are transitive, as explained in the history note above. 4. Named Individuals RiC-O adds six individuals to address current and frequent needs: FindingAid and AuthorityRecord, which are instances of both RiC-O Documentary Form Type and SKOS Concept. They can be used for categorizing Records, finding aids and authority records being considered as Records. For example, a Record with Documentary Form Type ‘Finding Aid’ may be connected to one to many Record Resources using the 'rico:describes’ object property. Fonds, Series, File, and Collection are instances of both Record Set Type class and skos:Concept. Their definition is taken from the ISAD(G) glossary. They can be used for categorizing Record Sets. We expect other categories to be defined by the archival community as RiC-O matures, forming rich, hopefully multilingual, SKOS vocabularies that support rich description (for example, allowing an instance of the Documentary Form Type class to have a history and temporal relations to other documentary form types). RiC-O documentation and annotation properties Each class or property has an English, a French and a Spanish label (rdfs:label), and a description (rdfs:comment). Some also have a skos:scopeNote or a skos:example. When a RiC-O class or property corresponds to a RiC-CM component in any way, its description and scope note are either the same as or derived from their RiC-CM definition and scope note. RiC-O provides two annotation properties (subproperties of rdfs:comment) for handling: information about the corresponding RiC-CM component when applicable (rico:RiCCMCorrespondingComponent). Various phrasings are used in this property depending on the rule applied for defining the RiC-CM component. information about possible mappings with other models or ontologies (rico:closeTo, rarely used in this 1.0.2 version)). Any change in the definition of a class or property made since December 2019 is documented using a skos:changeNote. Next steps The following is a non exhaustive list of known issues, topics or tasks on which EGAD has begun to work and will continue to work in the next months. articulate the Event and Activity classes, and the Relation system of classes add suggestions of mappings (in rico:closeTo) and OWL equivalences between some classes or properties and components in other models (among which - this is not an exhaustive list- PREMIS, Schema.org, PROV-O, IFLA-LRM and RDA, CIDOC-CRM), or document how these models can be used together.

The https://www.ica.org/standards/RiC/ontology# namespace defines:

2	owl:AnnotationProperty
105	owl:Class
61	owl:DatatypeProperty
400	owl:ObjectProperty
16	owl:SymmetricProperty
22	owl:TransitiveProperty

0 other term