| 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: 'hasOrHadPhysicalLocation' made a subproperty of
'isPlaceAssociatedWith'; 'isOrWasPhysicalLocationOf' made a subproperty of
'isAssociatedWithPlace'.</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='en' 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>
|
| 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'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> <owl:propertyChainAxiom
rdf:parseType="Collection"> <xhtml:br /> <rdf:Description
rdf:about="https://www.ica.org/standards/RiC/ontology#recordResourceOrInstantiationIsSourceOfAgentOriginationRelation"/>
<xhtml:br /> <rdf:Description
rdf:about="https://www.ica.org/standards/RiC/ontology#agentOriginationRelationHasTarget"/>
<xhtml:br /> </owl:propertyChainAxiom> </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'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) "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."</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 'date' 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 'flat' 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 '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>
|
![[RDF Data]](/fct/images/sw-rdf-blue.png)
