Methodology behind RIC-O
Arian Rajh
Florence Clavaud
Member of ICA/EGAD, lead of RiC-O team
Arian Rajh
Maristella Feustle
--
You received this message because you are subscribed to the Google Groups "Records_in_Contexts_users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to Records_in_Context...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/Records_in_Contexts_users/22588984-52a9-44c6-905a-62ec3916034an%40googlegroups.com.
Florence Clavaud
CLAVAUD Florence
Hi everybody,
I will try to answer these two questions in a few lines.
- As concerns the methodology followed to develop RiC-O
We did not follow any on the methods quoted by Arian, but we rather, building on, and extending, the previous existing ICA standards and the XML schemas that transpose them:
- simultaneously worked on the conceptual model and ontology.
One of the first main decisions was to build on a conceptual model that would be readable by any archivist and would stand as a generic framework, not to work directly and only on an OWL ontology. Such a conceptual model did not exist; though previous archival descriptions rules and standards had been published and were quite widely used particularly ISAD(G)), they are definitely not a conceptual model. And we had to develop it.
The RiC-O team, just to explain, is a subteam within EGAD, whose members also contribute actively to the other parts of RiC, including the CM, and now the application guidelines.
Working simultaneously on those two parts of RiC (the CM and the ontology) was and is fruitful, as we use RiC-O to test RiC-CM. Moreover, many ideas came from ontology modeling work
- spent a lot of time (and continue to do so) studying other ontologies, including the upper level Dolce one (http://www.loa.istc.cnr.it/dolce/overview.html; to be more accurate, we studied Dolce+DNS Ultralite), and CRM, FRBRoo and LRM. Also of course we had identified ontologies whose scope intersects RiC (like PREMIS of course, https://www.loc.gov/standards/premis/ontology/index.html, or PROV-O https://www.w3.org/TR/prov-o/, and also the W3C Organization ontology - https://www.w3.org/TR/vocab-org/; then later, among others, the Time ontology - https://www.w3.org/TR/owl-time/), and a few projects around the world aiming at this time to develop an ontology for archival description for specific projects (like the british LOCAH project)
- chose to systematically use some methods, naming conventions, or patterns, e.g. n-ary relations (https://www.w3.org/TR/swbp-n-aryRelations/) which seemed to be a good option to represent described, dated and complex relations as facts, just as for example ISAAR(CPF) already did in an abstract way (for example, the rico:OrganicProvenanceRelation is available to represent cases where one to many agents can together produce record resources); later on, OWL property chain axioms to build shortcuts.
- thoroughly tested RiC-O, as soon as we got early versions, i.e. in 2017, using existing archival metadata. One of these first expriments is the French PIAAF prototype (https://piaaf.demo.logilab.fr/), released in Feb. 2018 (see a presentation here, in English:https://enc.hal.science/hal-03958855)
- in late 2018 we publicly called for early reviewers of RiC-O, and got about 65 answers. In 2019, we submitted to these persons successive versions of RiC-O and got interesting feedback and questions from about ten persons, to which we answered, and whose feedback we tried to take into account
- in March 2020 we made the GitHub repository public, so that the development process has been open and transparent since that date. It already has involved persons out of the very small RiC-O development team
I want to insist on this: the early implementations we knew (as we either had been informed about them or managed them), and people who were interested in discussing issues with us, have been very helpul from Dec. 2019, and many decisions were made result
from the input or advice of these persons.
You can find other information about this in the following articles:
- https://doi.org/10.3828/comma.2016.18 (dated 2016; not yet publicly available)
- https://ceur-ws.org/Vol-3019/LinkedArchives_2021_paper_13.pdf (dated 2021)
Also, the introduction of RiC-O (that you can easily access and read from the HTML version; download the release and open in your browser the 'RiC-O_1.0_documentation.html' file that is in the ontology/current-version/HTML_view
folder), explains which design principles we followed; and can it can shed light on many of the features of RiC-O 1.0.
Basically, we wanted a domain reference ontology for describing any kind of archival records, something immediately usable, flexible (which relates to the very nature of archival description) and extensible - and also fully documented. Which really shaped the
outcome. This is also why I sometimes call RiC-O a transitional ontology (taking into account the current state of archival description). For now it results in something that is of course not perfect (not at all!), but quite consistent and that covers the
domain, and which works well in many situations, from very large projects to specific research ones.
Now, IMHO we only are at the beginning of the process. Among many other things that we can and will certainly do, we need to articulate RiC-O and other close ontologies that I have quoted (or at least explain how they can be used together), including PREMIS
and PROV-O, not to mention Schema.org. And of course we need to build a community of interest and practice, and to improve the ontology based on the feedback of this community.
Florence Clavaud
Executive member of ICA/EGAD ; lead of RiC-O development team
Conservatrice générale du patrimoine | General curator
Responsable du Lab des Archives nationales de France| head of the Lab, Archives
nationales de France
Envoyé : samedi 30 mars 2024 18:27
À : Records_in_Contexts_users
Objet : Re: [Records in Contexts users] Methodology behind RIC-O
Merci de nous aider à préserver l'environnement en n'imprimant ce courriel et les documents joints que si nécessaire.
Arian Rajh
CLAVAUD Florence
Dear Arian,
Thank you very much for this appreciation!
As concerns the translations of RiC-O labels into other languages than English: we first translated them into Spanish and Fench because these 3 languages are the official ICA languages - and also because some members of EGAD speak either French or Spanish, and could easily ask a few colleagues to produce translations collectively.
Now of course, it would be great if other translations are produced.
I think some colleagues are working on a German one.
If anybody would like to produce a new translation of the RiC-O labels, e.g. into Croatian ;-), you would be very welcome!
In order to do so, you could simply use the CSV files that are available at https://github.com/ICA-EGAD/RiC-O/tree/5b8d1b697823840f315c37df8d7bba5e927dbefa/ontology/current-version/CSV_lists_of_components, or in the release. They are UTF-8 encoded, with comma separated values, column values enclosed in quotation marks ('"')). They have been generated automatically from the ontology file.
Once downloaded, you could either open these files using an open source software like Apache OpenOfffice (https://www.openoffice.org/), or import them into MS Excel. There is one file per RiC-O component type, so one for the classes, one for the datatype properties, one for the object properties. Then, you could add a column to each of these files and type the translated labels in this column. You can remove any of the provided columns, except the first one (that contains the URI of the component) and the second one that contains the English labels; you can also change the order of the columns, as long as you do not change their title or content.
You may need the columns that contain the description/definition and scope notes of the components in order to produce an accurate translation, and also work with a group of colleagues.
Once you have completed the translation, you could either share it using this list, or create an issue on the public repository on GitHub and link the file to it, or else send an email to me (see below). We will then automatically include the new labels
in the ontology file; and also regenerate the HTML documentation.
Let me add that we may in the future consider storing the translations in separate files, and make the modularized version of RiC-O the reference one, in order not to get a too big unique OWL file. It will depend on the existence of new translations, and on
other developments.
Also, of course, the translation could concern the whole RiC-O specification in the future. This would be a much more heavy task, that would also be bound to the translation of RiC-CM 1.0, as many components of RiC-O have exactly the same definition or scope note, or even examples as RiC-CM. So it would be managed other ways.
As concerns your second question: we have not yet a precise and complete work plan or roadmap for the future major version of RiC-O, though we have already created a few issues and also have other tasks in mind. The extended model you are talking about looks very interesting. We have already started to model certain attributes of RiC-CM more precisely, such as *extent, location and coordinates. Unless I have misunderstood, this extended model is already in use and therefore meets the needs of the persons who created it. And we would like to develop RiC-O by taking into account the needs and expectations of which we are aware. So we would be glad if we can either access this extended model, or contact the persons who created it.
If the extensions made seem to be of general interest, we could take them into account, in one way or another, in a future version of RiC-O.
Best regards,
Florence Clavaud
Executive member of ICA/EGAD ; lead of RiC-O development team
Conservatrice générale du patrimoine | General curator
Responsable du Lab des Archives nationales de France| head of the Lab, Archives
nationales de France
Envoyé : samedi 13 avril 2024 14:23
Arian Rajh
Arian Rajh
CLAVAUD Florence
Dear Arian,
I can confirm that, unless I have missed something, RiC-O as it is now (RiC-O 1.0.1) is an OWL 2 DL ontology.
The only condition it does not satisfy for now (again, unless I have missed something, which is possible), which is fact an OWL 2 condition, is that it does not have a version IRI (owl:versionIRI), while it should have in order to be clearly distinguished from the former versions (see https://www.w3.org/TR/owl2-syntax/#Ontology_IRI_and_Version_IRI). Which we can fix in the next version.
About RiC-O and the OWL 2 profiles: after spending time checking the OWL 2 profiles specification (https://www.w3.org/TR/owl2-profiles/), what I can say is that, again unless I have missed something, which is possible:
- RiC-O 1.0.1 is far from the OWL EL or QL profiles.
In particular, and among other features, it defines inverse object properties and symmetric object properties, which is not supported by OWL EL.
It defines transitive object properties and property chain axioms, which is not supported by OWL QL.
- RiC-O 1.0 is close to the OWL RL profile specification.
However, it defines reflexive properties and uses owl:hasSelf, which are not supported by OWL RL.
To be more precise, in RiC-O there is for now an issue about those reflexive properties, which we will fix (probably by deleting the assertions about the reflexiveness of those properties). But owl:hasSelf will remain after that. However, owl:hasSelf is
used to define Relation classes only.
As a consequence, everything in RiC-O 1.0.1 which is not about the Relation classes is compliant with the OWL 2 RL profile. So, if you definitely want to only get the subset of RiC-O that is compliant with the OWL 2 RL profile, you could use the modularized version (see https://github.com/ICA-EGAD/RiC-O/tree/master/ontology/current-version/modularized-version) and follow the method explained there for use case 1.
In fact the most important is your data and needs, and also what you can do with the specific tools (graph bases and reasoners) you are using. RiC-O, though being only a high level domain ontology, provides (of course) a basis for reasoning. But you can also extend the ontology, and/or use specific inference constructs or rules adapted to your data.
Let me add that we may modify the Relation classes definition in a future version of RiC-O, which may result in the whole of RiC-O being compliant with the OWL 2 RL profile.
My two cents.
Best regards,
Florence
Florence Clavaud
Executive member of ICA/EGAD ; lead of RiC-O development team
Conservatrice générale du patrimoine | General curator
Responsable du Lab des Archives nationales de France| head of the Lab, Archives nationales de France
email : florence...@culture.gouv.fr
À : Records_in_Contexts_users
Objet : Re: [Records in Contexts users] Methodology behind RIC-O
Dear all, I have one additional question regarding this subject: Is RIC-O an OWL DL ontology or an OWL full ontology? I'm asking because of the implications of RIC-O design for automatic reasoning and decidability. My guess is it is an OWL DL ontology with direct semantics founded on the OWL2 standard (which is founded from SROIQ description logic (DL) language). But I'm not sure.
Arian Rajh
Arian Rajh
CLAVAUD Florence
Hi Arian,
As concerns step 2: for now, in order to add the French and Spanish labels (stored in three CSV files) to the main RiC-O RDF/XML file, I have written an XSLT script. It is part of a set of scripts that we use to manage RiC-O, and that we could make public (once checked and fully documented).
As I said below, we (I mean the RiC-O development team) could do this conversion for you once you have prepared the CSV files; we would be glad to be able to add labels to RiC-O in other languages than English, French and Spanish. As I already said too, we may choose to manage translations of RiC-O English labels and internal documentation using distinct files, one for each language, and make the modularized version that already exists (https://github.com/ICA-EGAD/RiC-O/tree/master/ontology/current-version/modularized-version) the main, reference, RiC-O file.
You may also be interested in managing by yourself your own, say local or specific, translation, in a separate RDF file, as an extension of RiC-O, that would have its own URI and import the RiC-O file using owl:imports. Then, when you would open this extension file in Protégé, this tool would be able to display everything in the same Protégé window, as if you would have one file only.
As concerns step 3: if what you would like to do is view RiC-O classes and properties (or the components of any other OWL ontology) in Protégé through their labels in some language, you could simply:
- open the ontology file in Protégé
- choose View > Render by label
- then if needed, adjust the way Protégé displays the labels by doing View > Custom rendering, and configuring the entity rendering
Hope this helps,
Florence Clavaud
Executive member of ICA/EGAD ; lead of RiC-O development team
Conservatrice générale du patrimoine | General curator
Responsable du Lab des Archives nationales de France| head of the Lab, Archives nationales de France