This HTML5 document contains 24 embedded RDF statements represented using HTML+Microdata notation.

The embedded RDF content will be recognized by any processor of HTML5 Microdata.

Subject Item

n2:ontology

rdf:type

owl:NamedIndividual owl:Ontology n9:Vocabulary

rdfs:label

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

owl:versionInfo

Version 0.2 - 2021-02-12.

owl:priorVersion

n8:rdf

skos:historyNote

<xhtml:div xmlns:xhtml="http://www.w3.org/1999/xhtml" xml:lang="en"> <xhtml:p>A first beta version of RiC-O was developed in 2017 and used by the National Archives of France for building a proof of concept (<xhtml:a href="https://piaaf.demo.logilab.fr">https://piaaf.demo.logilab.fr</xhtml:a>).</xhtml:p> <xhtml:p>EGAD then continued to develop the ontology, and this process entered a very active period in 2019, while RiC-CM v0.2 was being designed and edited. From December 2018 to November 2019, about 65 persons that had applied to a call for reviewers, received successive beta versions of RiC-O and sent a few first comments. While EGAD RiC-O team could not answer to each of these comments, each was taken into account. In particular, it was decided to prepare and publish, along with RiC-O v0.1, a preview of RiC-CM v0.2. The goal of the preview release of RiC-CM v0.2 is to provide context for the classes, properties, and overall logic of RiC-O in support of the ontology’s first public release. RiC-O v0.1 was released on December 2019, 12.</xhtml:p> <xhtml:p>The Git repository that is used for handling RiC-O was made public in March 2020 (see <xhtml:a href="https://github.com/ICA-EGAD/RiC-O">https://github.com/ICA-EGAD/RiC-O</xhtml:a>), so that creating issues or comments, forking and making pull requests was made possible.</xhtml:p> <xhtml:p>In 2020, RiC-CM v0.2 preview was significantly updated: the textual definitions of many entities were changed, as well as the specifications of many attributes; and a lot of relations changed name, in order to take into account past situations and to adopt some simple naming rules. As a consequence, RiC-O had to be updated in order to remain compliant with RiC-CM. These changes could not be made before the end of 2020, when RiC-CM could be considered stable. EGAD also decided to make other changes in RiC-O, among which the most important are mentioned in bold in the following list.</xhtml:p> <xhtml:p>RiC-O 0.2 results from these updates and changes. It has been released a few weeks before RiC-CM 0.2 full draft, and is fully compliant with it.</xhtml:p> <xhtml:p>The following is a list of the changes made to RiC-O (this current version being RiC-O v0.2) since the release of RiC-O v0.1 in December 2019. The most important changes are mentioned in bold. Note that from October 2020 any change on a component is described and dated in the specification of this component, using skos:changeNote.</xhtml:p> <xhtml:ul> <xhtml:li>Fixed a bug in the documentation of rico:PerformanceRelation and its object properties.</xhtml:li> <xhtml:li>Renamed the file and updated the ontology metadata.</xhtml:li> <xhtml:li>OccupationType made a subclass of ActivityType.</xhtml:li> <xhtml:li>Changed the domain and range of rico:hasOriginal and rico:hasDraft (it is now Record or Record Part); same for their inverse properties.</xhtml:li> <xhtml:li>Fixed a bug in the definition of rico:provenanceRelationHasTarget (removed the owl:propertyChainAxiom).</xhtml:li> <xhtml:li>Changed the name of rico:leadBy object property (grammatical mistake) to rico:ledBy. </xhtml:li> <xhtml:li>2020, October 19: Added a vann:preferredNamespaceUri and vann:preferredNamespacePrefix property to the ontology metadata</xhtml:li> <xhtml:li>2020, October 19 : created RuleType and IdentifierType classes, along with the associated object properties.</xhtml:li> <xhtml:li>2020, October 23: <xhtml:strong>updated the text definition and/or scope note of 33 classes, that correspond to RiC-CM entities or attributes, in order to make them compliant with RiC-CM v0.2</xhtml:strong>. Added a few owl:disjointWith properties.</xhtml:li> <xhtml:li>2020, November 1: <xhtml:strong>updated the text definition and/or scope note of, and/or added examples for, 27 datatype properties, that correspond to RiC-CM attributes, in order to make them compliant with RiC-CM v0.2</xhtml:strong>.</xhtml:li> <xhtml:li>2020, November 20: <xhtml:strong>created new classes and properties for handling an accurate description of instantation and record resource extent</xhtml:strong>: Extent, Carrier Extent, Instantiation Extent, Record Resource Extent, Unit of measurement, Extent Type classes; unit of measurement and quantity datatype properties; has Extent, is Extent Of, has Extent Type, is Extent Type Of, has Unit Of Measurement, is Unit of Measurement Of, object properties.</xhtml:li> <xhtml:li>2020, December 28: changed the IRIs and definition of RecordResourceState class and of the associated object properties; <xhtml:strong>changed the domain or ranges and textual definitions of properties associated with Language, LegalStatus, ContentType, DocumentaryFormType; added new object properties for handling the description of some or all members of Record Set</xhtml:strong>. Added the corresponding change notes.</xhtml:li> <xhtml:li>2020, December 29: deleted the isSuperiorTo and isInferiorTo object properties, as well as the AgentSubordinationRelation and its object properties (as the RiC-R043 relation has been removed from RiC-CM 0.2). Added the hasAuthor/isAuthorOf object properties, plus an AuthorshipRelation class and its specific object properties (as the RiC-R079 relation has been added to RiC-CM 0.2). Added the corresponding change notes.</xhtml:li> <xhtml:li>2021, January 22: <xhtml:strong>changed the IRI, label, and/or superproperties or inverse property IRI, and/or textual definition, and/or domain or range, of 152 object properties. Among them, changed the IRI of 119 object properties; 85 correspond to RiC-CM relations whose name has been changed in RiC-CM 0.2</xhtml:strong>. Added the corresponding change notes.</xhtml:li> <xhtml:li>2021, January 27: added an rdfs:isDefinedBy to the specification of each RiC-O class and property and made the last changes to the ontology metadata (mainly in the history note).</xhtml:li> <xhtml:li>2021, February 1: last small changes in the ontology metadata (mainly in the abstract).</xhtml:li> <xhtml:li>2021, February 1: &#39;hasOrHadPhysicalLocation&#39; made a subproperty of &#39;isPlaceAssociatedWith&#39;; &#39;isOrWasPhysicalLocationOf&#39; made a subproperty of &#39;isAssociatedWithPlace&#39;.</xhtml:li> <xhtml:li>2021, February 1: reordered everything with Protégé without changing the content</xhtml:li> <xhtml:li>2021, February 4: checked and fixed the language of the examples.</xhtml:li> <xhtml:li>2021, February 8: removed a few Restriction classes (rdfs:subClassOf/owl:Restriction) in the definition of classes; completed the textual definition and scope note of the Relation class.</xhtml:li> <xhtml:li>2021, February 9: added a link to RiC-CM 0.2 diagram overview in the introduction; fixed some typos.</xhtml:li> <xhtml:li>2021, February 11: added an @xml:lang=&#39;en&#39; on a few labels; updated the definition (rdfs:comment) and scope note of the Rule class, as they were recently changed in RiC-CM 0.2 full draft.</xhtml:li> </xhtml:ul> </xhtml:div>

dc:contributor

Tobias Wildi (Docuteam GmbH, Switzerland), member of EGAD Miia Herrala (National Archives of Finland), member of EGAD Daniel Pitti (University of Virginia, USA), chair of EGAD Aaron Rubinstein (University of Massachusetts Amherst, USA), member of EGAD

dc:rights

Copyright 2019-...., International Council on Archives (ICA)

dct:abstract

<xhtml:div xmlns:xhtml="http://www.w3.org/1999/xhtml" xml:lang="en"> <xhtml:p>RiC-O (Records in Contexts-Ontology) is an OWL ontology for describing archival record resources. As the second part of Records in Contexts standard, it is a formal representation of Records in Contexts Conceptual Model (RiC-CM). </xhtml:p> <xhtml:p>The current official version is <xhtml:strong>v0.2</xhtml:strong>; it is compliant with RiC-CM v0.2 full draft, that will be published in February or March 2021, and that is slightly different from <xhtml:a href="https://www.ica.org/sites/default/files/ric-cm-0.2_preview.pdf">RiC-CM v0.2 preview</xhtml:a>, that was published in December 2019.</xhtml:p> <xhtml:p>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 can support publishing RDF datasets as Linked Data, querying them using SPARQL, and making inferences using the logic of the ontology.</xhtml:p> </xhtml:div>

dct:contributor

n10:0000000039584825

n11:preferredNamespacePrefix

rico

n11:preferredNamespaceUri

https://www.ica.org/standards/RiC/ontology#

n14:license

n15:

dct:title

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

dc:creator

Florence Clavaud (Archives nationales de France), member of EGAD, lead of EGAD RiC-O team International Council on Archives Expert Group on Archival Description (ICA EGAD)

dct:description

<xhtml:div xmlns:xhtml="http://www.w3.org/1999/xhtml" xml:lang="en" id="introduction"> <xhtml:h3>Introduction</xhtml:h3> <xhtml:p>RiC-O (Records in Contexts-Ontology) is an OWL ontology for describing archival record resources. As the second part of Records in Contexts standard, it is a formal representation of Records in Contexts Conceptual Model (RiC-CM). This version, which is v0.2, is the current official release. It is compliant with RiC-CM v0.2, that will be published soon after the release of RiC-O v0.2.</xhtml:p> <xhtml:p>The following diagram shows the main RiC-CM v0.2 entities and a few relations between them: <xhtml:img src="https://raw.githubusercontent.com/ICA-EGAD/RiC-O/master/diagrams/diagrams_v0-2/RiC-CM-overview/diagram_RiC-CM-overview-RiC-v0-2.jpg" alt="A partial overview of RiC-CM v0.2 main entities" class="diagram" /> </xhtml:p> <xhtml:div id="design-principles"> <xhtml:h4>RiC-O design principles</xhtml:h4> <xhtml:p>The following design principles were followed when developing RiC-O.</xhtml:p> <xhtml:p> <xhtml:strong>RiC-O is a domain or reference ontology</xhtml:strong>.</xhtml:p> <xhtml:p>It 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 can support publishing RDF datasets as Linked Data, querying them using SPARQL, and making inferences using the logic of the ontology.</xhtml:p> <xhtml:p>While some projects have built some specific ontologies for describing archives, at this time no generic domain ontology exists for the specific needs of the archival community. This is why EGAD decided to develop RiC-O as the second part of RiC standard.</xhtml:p> <xhtml:p>Apart this first, main target, RiC-O also can help archival institutions and engineers to design and develop other technical implementations of RiC-CM that represent record resources and their layers of contexts as oriented, interconnected graphs. Of course, other technical implementations may be developed later on, including XML models, or (hopefully) new versions of EAD and EAC-CPF XML models.</xhtml:p> <xhtml:p>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 a project can either limit itself to the use of a selection of components, or can add more subcomponents where needed.</xhtml:p> <xhtml:p>As a domain ontology, RiC-O, at this stage at least, does not borrow any component 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.</xhtml:p> <xhtml:p>Later on, RiC-O will be aligned with these existing models. 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.</xhtml:p> <xhtml:p> <xhtml:strong>RiC-O must be immediately usable.</xhtml:strong> </xhtml:p> <xhtml:p>This is a key feature for a new model. In particular, it is very important that existing archival metadata, that are created or generated in current information systems, can be converted to RDF conforming to RiC-O, without losing any data, structural or partially implicit information. What is at stake here is that metadata conforming to the previous existing ICA standards can be processed successfully.</xhtml:p> <xhtml:p>During the ongoing development process, a lot of successful testing has been made, using XML/EAD finding aids and XML/EAC-CPF authority records, that have been converted to RDF datasets, either by hand or using scripts. A conversion software is being developed and will soon be available.</xhtml:p> <xhtml:p>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 should remain possible. In order to allow this, RiC-O sometimes provides several methods for representing information (as described below). From this point of view, the current official version of RiC-O may be considered a transitional ontology, in which some components may be deprecated later on.</xhtml:p> <xhtml:p> The usability of a model also depends on its documentation. That’s why the current official release has been fully documented (this documentation will be continously improved).</xhtml:p> <xhtml:p>RiC-O will also soon be acompanied with examples (RDF datasets). Some tutorials should also be written, and EGAD will organize practical workshops.</xhtml:p> <xhtml:p> <xhtml:strong>RiC-O has to provide a flexible framework</xhtml:strong>.</xhtml:p> <xhtml:p>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 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.</xhtml:p> <xhtml:p>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 should provide several methods for expressing whether relations are well attested and certain, or are more vague, as well as direct and short paths between entities alongside more complex ones.</xhtml:p> <xhtml:p> <xhtml:strong>RiC-O opens new potential for archival description.</xhtml:strong> </xhtml:p> <xhtml:p>This means that Linked Data tools and interfaces should enable end users to go through RDF/RiC-O graphs, to query them using SPARQL in an efficient way and to consult archival metadata and their contexts in new ways. As an example, an end user should be able to ask « What are (according to your dataset) the corporate bodies that succeeded to this given entity from its end of existence, by 1840, to nowadays (as concerns this given activity) ?» or « tell me what instantiations of this photograph exist? » « what are the existing copies of this original charter?», and get a list of these entities. In other words, institutions or projects that make the effort to implement RiC-O will get new insight into the content and context of their archives that wasn&#39;t visible with the existing ICA-standards. It should be even more interesting if you can infer new assertions from the RDF datasets you built, and of course link your datasets to other ressources outside of your institution.</xhtml:p> <xhtml:p> <xhtml:strong>RiC-O should be extensible</xhtml:strong>.</xhtml:p> <xhtml:p>Institutions are free to extend the ontology by adding new subclasses or subproperties if needed. RiC-O has also the potential to be useable in other contexts than purely archival ones. This implies that hierarchies of classes and properties are defined and that mappings are developed with other ontologies as mentioned above. It may also imply that RiC-O should provide “hooks” enabling connections with, for example, existing SKOS vocabularies.</xhtml:p> </xhtml:div> <xhtml:div id="understanding-RiCO"> <xhtml:h4>Understanding RiC-O: a quick overview of some features</xhtml:h4> <xhtml:div id="fromRiCCM-to-RiCO"> <xhtml:h5>From RiC-CM to RiC-O</xhtml:h5> <xhtml:p>In the <xhtml:strong>system of classes of RiC-O,</xhtml:strong> for each RiC-CM entity, you can find a corresponding class. These classes are organized according to the same hierarchy as in RiC-CM. In some projects, you may need very few of them (e.g. Agent, Record Resource and Activity only), while in other ones, you may need more (e.g. Corporate Body and Person; Record; Place; Provenance Relation).</xhtml:p> <xhtml:p>Certain classes only exist in RiC-O and not in RiC-CM. These additional classes address special needs:</xhtml:p> <xhtml:ul> <xhtml:li>some correspond to RiC-CM attributes, when it may be considered necessary to handle them as full entities. This is the case for <xhtml:a href="#rico:Type">Type</xhtml:a> 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 <xhtml:a href="#rico:Language">Language</xhtml:a>, <xhtml:a href="#rico:Name">Name</xhtml:a> and <xhtml:a href="#rico:Identifier">Identifier</xhtml:a>, that can be considered as full entities and as key linking nodes in a RDF graph. All these classes have been grouped under a <xhtml:a href="#rico:Concept">Concept</xhtml:a> class. </xhtml:li> <xhtml:li>some classes have been added in order to provide a more accurate definition and model for some entities. <xhtml:a href="#rico:Place">Place</xhtml:a> thus comes along with a <xhtml:a href="#rico:PhysicalLocation">Physical Location class</xhtml:a>, and with a <xhtml:a href="#rico:Coordinates">Coordinates class</xhtml:a>. 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 (<xhtml:a href="https://github.com/LinkedPasts/linked-places">https://github.com/LinkedPasts/linked-places</xhtml:a>). Another example of such an addition is the <xhtml:a href="#rico:Proxy">Proxy class</xhtml:a>, that represents (stands for) a Record Resource as it exists in a specific Record Set.</xhtml:li> <xhtml:li>finally, a system of classes helps to implement the Relations section of RiC-CM.<xhtml:br /> While these relations also are represented as simple, binary object properties (e.g. <xhtml:a href="#rico:hasProvenance">‘hasProvenance’</xhtml:a> 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. RDF* and SPARQL* 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 <xhtml:a href="https://w3c.github.io/rdf-star/">https://w3c.github.io/rdf-star/</xhtml:a>) and is already being used by some tools; however it is not yet a W3C standard. Thus, for example, in RiC-O an <xhtml:a href="#rico:AgentOriginationRelation">AgentOriginationRelation class</xhtml:a> 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 ‘hasProvenance’ object property, let us add that it is formally defined in RiC-O, using OWL 2 property chain axiom (see <xhtml:a href="https://www.w3.org/TR/owl2-new-features/">https://www.w3.org/TR/owl2-new-features/</xhtml:a>, as a ‘shortcut’ for the longer path ‘recordResourceOrInstantiationIsSourceOfAgentOriginationRelation/agentOriginationRelationHasTarget’, where the intermediate node is an instance of Agent Origination Relation:<xhtml:br /> <xhtml:code> &lt;owl:propertyChainAxiom rdf:parseType=&quot;Collection&quot;&gt; <xhtml:br /> &lt;rdf:Description rdf:about=&quot;https://www.ica.org/standards/RiC/ontology#recordResourceOrInstantiationIsSourceOfAgentOriginationRelation&quot;/&gt; <xhtml:br /> &lt;rdf:Description rdf:about=&quot;https://www.ica.org/standards/RiC/ontology#agentOriginationRelationHasTarget&quot;/&gt; <xhtml:br /> &lt;/owl:propertyChainAxiom&gt; </xhtml:code> <xhtml:br />A triplestore, with the appropriate configuration, may thus infer the direct ‘hasProvenance’ assertion from this long path.</xhtml:li> </xhtml:ul> <xhtml:p>Most of the <xhtml:strong>datatype properties in RiC-O </xhtml:strong>correspond to RiC-CM attributes that contain free, plain text. See for example <xhtml:a href="#rico:descriptiveNote">rico:descriptiveNote</xhtml:a>, <xhtml:a href="#rico:history">rico:history</xhtml:a> and <xhtml:a href="#scopeAndContent">rico:scopeAndContent</xhtml:a>.</xhtml:p> <xhtml:p>In addition to these datatype properties, the Name and Identifier RiC-CM attributes also have corresponding classes (subclasses of <xhtml:a href="#rico:Appellation">rico:Appellation</xhtml:a>). A resource may have several Identifiers and each comes with different attributes (e.g. archival reference code, system number, digital object identifier), in this case the identifiers will be modelled in a class. In many simpler usecases it&#39;s sufficent to just use the <xhtml:a href="#rico:identifier">identifier datatype property</xhtml:a>, typically for the archival reference code.</xhtml:p> <xhtml:p>The Location RiC-CM attribute also has a <xhtml:a href="#rico:PhysicalLocation">rico:Physical Location corresponding class</xhtml:a> (for users who want to use Place, Physical Location and Coordinates for handling places).</xhtml:p> <xhtml:p>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. 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.</xhtml:p> <xhtml:p>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 <xhtml:a href="#rico:type">rico:type datatype property</xhtml:a>, with range rdfs:literal, which allows you to move forward.</xhtml:p> <xhtml:p>Therefore, for the RiC-CM *Type attributes, you have a corresponding <xhtml:a href="#rico:type">rico:type datatype property</xhtml:a>. For RiC-CM Coordinates attribute, you also have <xhtml:a href="#rico:geographicalCoordinates">rico:geographicalCoordinates datatype property</xhtml:a>.</xhtml:p> <xhtml:p>These datatype properties have a skos:scopeNote which says (for example) &quot;Provided for usability reasons. May be made deprecated or removed later on. Use only if you don&#39;t use Physical Location and Coordinates classes with Place.&quot;</xhtml:p> <xhtml:p>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 &#39;date&#39; datatype properties; plus a <xhtml:a href="#rico:ruleFollowed">rico:ruleFollowed datatype property</xhtml:a>. The same analysis led us to keep the <xhtml:a href="#rico:history">rico:history</xhtml:a> datatype property in RiC-O (same as RiC-CM history attribute), while RiC-CM and RiC-O also provide the <xhtml:a href="#rico:Event">Event class</xhtml:a>, 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.</xhtml:p> <xhtml:p>These datatype properties have the same kind of skos:scopeNote as above.</xhtml:p> <xhtml:p>Finally, we have introduced a few datatype properties that do not correspond to any RiC-CM attribute.</xhtml:p> <xhtml:p>Some are superproperties, and thus group datatype properties (<xhtml:a href="#rico:physicalOrLogicalExtent">rico:physicalOrLogicalExtent</xhtml:a>, with rico:carrierExtent, rico:instantiationExtent and rico:recordResourceExtent as subproperties ; <xhtml:a href="#rico:textualValue">rico:textualValue</xhtml:a>, with rico:expressedDate and rico:normalizedValue as subproperties; <xhtml:a href="#rico:measure">rico:measure</xhtml:a> (and its subproperties); <xhtml:a href="#rico:referenceSystem">rico:referenceSystem</xhtml:a>, superproperty of rico:dateStandard (and of other datatype properties that do not exist in RiC-CM.)</xhtml:p> <xhtml:p>Some are simply more specific properties : <xhtml:a href="#rico:accrualStatus">rico:accrualStatus</xhtml:a> ; <xhtml:a href="#rico:recordResourceStructure">rico:recordResourceStructure</xhtml:a> and <xhtml:a href="#rico:instantiationStructure">rico:instantiationStructure</xhtml:a>, subproperties of rico:structure ; <xhtml:a href="#rico:title">rico:title</xhtml:a> (subproperty of rico:name) ; rico:altitude, rico:latitude, rico:longitude (subproperties of rico:measure), rico:geodesicSystem and rico:altimetricSystem (subproperties of rico:referenceSystem).</xhtml:p> <xhtml:p>In order to connect all the classes created, <xhtml:strong>a significant number of object properties have been defined</xhtml:strong>. While their &#39;flat&#39; list is a long one, they 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. As already said above, some of the object properties are also formally defined as shortcuts.</xhtml:p> <xhtml:p>Finally, let us mention that we added to RiC-O six individuals, considering that they would address current and frequent needs:</xhtml:p> <xhtml:ul> <xhtml:li>Two (<xhtml:a href="#FindingAid">FindingAid</xhtml:a> and <xhtml:a href="#AuthorityRecord">AuthorityRecord</xhtml:a>) 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. A Record that would have ‘Finding Aid’ as a Documentary Form Type, can be connected to one to many Record Resources using &#39;rico:describes’ object property.</xhtml:li> <xhtml:li>Four (<xhtml:a href="#Fonds">Fonds</xhtml:a>, <xhtml:a href="#Series">Series</xhtml:a>, <xhtml:a href="#File">File</xhtml:a>, and <xhtml:a href="#Collection">Collection</xhtml:a>) are both instances of the Record Set Type class, and of skos:Concept. Their definition is taken from the ISAD(G) glossary. They can be used for categorizing Record Sets.</xhtml:li> </xhtml:ul> <xhtml:p>In the future, we can imagine that many other categories of the kind will be defined by the archival community, forming at least rich SKOS (hopefully multilingual) vocabularies. Considering the concepts thus defined as being also instances of some RiC-O classes may be of great interest for producing a richer description (for example, an instance of the <xhtml:a href="#rico:DocumentaryFormType">Documentary Form Type class</xhtml:a> may have a history and some temporal relations to other documentary form types).</xhtml:p> </xhtml:div> <xhtml:div id="RiCO-documentation"> <xhtml:h5>RiC-O documentation and annotation properties</xhtml:h5> <xhtml:p>Each class or property has at least an English label (rdfs:label) and description (rdfs:comment). Some have a skos:scopeNote or a skos:example.</xhtml:p> <xhtml:p>When a RiC-O class or property corresponds in a way to a RiC-CM component, its description and scope note are, either the same as, or derived from, their definition and scope note in RiC-CM.</xhtml:p> <xhtml:p>We have created two annotation properties, subproperties of rdfs:comment, for handling:</xhtml:p> <xhtml:ul> <xhtml:li>Information about the corresponding RiC-CM component when appliable (<xhtml:a href="#rico:RiCCMCorrespondingComponent">rico:RiCCMCorrespondingComponent</xhtml:a>). Various phrasings are used in this property depending on the rule applied for defining the RiC-CM component.</xhtml:li> <xhtml:li>Information, most often in prose text for now, about possible mappings with other models or ontologies (<xhtml:a href="#rico:closeTo">rico:closeTo</xhtml:a>, rarely used in this 0.1 version)).</xhtml:li> </xhtml:ul> <xhtml:p>Finally, in this official 0.2 release, any change in the definition of a class or property, since December 2019, is documented using a skos:changeNote.</xhtml:p> </xhtml:div> </xhtml:div> <xhtml:div id="next-steps"> <xhtml:h4>Next steps</xhtml:h4> <xhtml:p>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:</xhtml:p> <xhtml:ul> <xhtml:li>providing more examples of known implementations of RiC-O in different institutions and contexts. The goal is to show different practices on how RiC-O is being implemented. We have begun to release such examples in the <xhtml:a href="https://github.com/ICA-EGAD/RiC-O">public RiC-O repository on GitHub</xhtml:a>. One can also have a look at the <xhtml:a href="https://ica-egad.github.io/RiC-O/projects-and-tools.html">Projects and tools page on RiC-O website</xhtml:a>.</xhtml:li> <xhtml:li>finishing the system of relations (where some subclasses are still missing)</xhtml:li> <xhtml:li>assessing, and changing in some cases, the tense of the verbs in some object properties (e.g. for the properties that correspond to some RiC-CM relations). This has been done, following RiC-CM v0.2 updates, where many relations have changed name so that they can be used for recording both past and present situations.</xhtml:li> <xhtml:li>articulating the Event and Activity classes, and the Relation system of classes</xhtml:li> <xhtml:li>improving the names of object properties. This has been done, following RiC-CM v0.2 updates and applying a few naming rules, so that, for example, the same verb is used for naming a relation and the inverse relation when it exists.</xhtml:li> <xhtml:li>adding 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- CIDOC-CRM, IFLA-LRM, PREMIS, PROV-O, Wikidata and Schema.org)</xhtml:li> <xhtml:li>documenting RiC-O in French and Spanish</xhtml:li> <xhtml:li>providing users with some SPARQL constructs for inferring.</xhtml:li> </xhtml:ul> </xhtml:div> </xhtml:div>

dct:creator

n7:about

dc:publisher

International Council on Archives

dct:publisher

n6:Q1421986