RiC-O and Linked Open Data

[Pavel Zhelnov]

Dear group,

When modeling new entities and relationships as part of a proof-of-concept implementation of RiC-O at the Archives of Ontario, we had a few questions that we could not address with certainty, so I am reaching out for advice:

#1

Can any Linked Open Data entity be assumed to be a rico:Thing even if not asserted? If not, should a non-RiC-O object property always be used when modeling linkages to Linked Open Data entities (e.g., rdfs:seeAlso) given that even rico:isEquivalentTo can only operate within the range of rico:Thing?

#2 (related to #1)

Is it considered appropriate to add statements to our own dataset about URIs from other Linked Open Data (e.g., wikidata:Q787456 a rico:Person)? If not and a “proxy” entity needs to be created within our dataset (e.g., ex:John_Robarts a rico:Person; rdfs:seeAlso wikidata:Q787456), does it mean that each archives will have to create their own RiC-O compliant entity for the same Linked Open Data entity (e.g., wikidata:Q787456 in this case)?

#3

Were/are there plans to create a generic object property class and a generic datatype property class within RiC-O (e.g., rico:datatypeProperty and rico:objectProperty) so that those could be extended by implementing archives if necessary? At this time, all RiC-O properties are only instances of OWL property classes, and no RiC-O specific classes exist, so when a custom property needs to be defined, it can only be defined as an OWL property on its own without any linkage to RiC-O or RiC-O specific classes. To give a specific example, we needed to model ex:accumulationDate before RiC-O 1.1 was released (which now defines rico:accumulationDate), and we only managed to define it as a owl:DatatypeProperty; rdfs:subPropertyOf rico:date, ex:datatypeProperty (we had to define the latter within our own schema as well).

Thanks in advance!

Pavel

--

Pavel Zhelnov

[CLAVAUD Florence]

Dear Pavel,

Just a few quick words about your questions:

"#1

Can any Linked Open Data entity be assumed to be a rico:Thing even if not asserted? If not, should a non-RiC-O object property always be used when modeling linkages to Linked Open Data entities (e.g., rdfs:seeAlso) given that even rico:isEquivalentTo can only operate within the range of rico:Thing?"

Yes, any entity you would need to describe in your archival metadata can be assumed to be a rico:Thing, and once this is asserted you can use the RiC-O datatype properties or project properties whose domain or range is rico:Thing, to connect this entity with literals or other entities. Besides, using simple RDFS entailment rules, even if you do not assert explicitly that some entity is a RiC-O Thing  (I mean rdf:type rico:Thing), if you use for it a property whose domain is rico:Thing, e.g. the rico:name datataype property, it entails that the entity is a rico:Thing.

As concerns rico:isEquivalentTo, I am realizing that this property may cause confusion and that we should work on this. It is not at all similar with owl:sameAs or rdfs:seeAlso, it is about two distinct entities. It was introduced as a superentity for rico:isFunctionallyEquivalentTo, which can only be used in very specific situations to connect two distinct instantiations.  

 

#2 (related to #1)

Is it considered appropriate to add statements to our own dataset about URIs from other Linked Open Data (e.g., wikidata:Q787456 a rico:Person)? If not and a “proxy” entity needs to be created within our dataset (e.g., ex:John_Robarts a rico:Person; rdfs:seeAlso wikidata:Q787456), does it mean that each archives will have to create their own RiC-O compliant entity for the same Linked Open Data entity (e.g., wikidata:Q787456 in this case)?

If you consider that wikidata:Q787456 is a rico:Person, which seems correct, yes of course, you can add statements of the kind to your data. Basically, this is about mapping two models and datasets.

In such a case, if I am sure that ex:John_Robarts (the person I have described in my dataset) is the same person as the one described in Wikidata, I would use ex:John_Robarts owl:sameAs wikidata:Q787456; not only rdfs:seeAlso.

You could also consider this situation another way: do you need to describe John Robarts in you dataset (or do you manage important data about him in your system), or would it be enough for you to connect the Wikidata graph about John Robarts to you own graph? if so, simply use wikidata:Q787456 to identify John Robarts in your own graph, and the two graphs will be connected to each other. 

"#3

Were/are there plans to create a generic object property class and a generic datatype property class within RiC-O (e.g., rico:datatypeProperty and rico:objectProperty) so that those could be extended by implementing archives if necessary? At this time, all RiC-O properties are only instances of OWL property classes, and no RiC-O specific classes exist, so when a custom property needs to be defined, it can only be defined as an OWL property on its own without any linkage to RiC-O or RiC-O specific classes. To give a specific example, we needed to model ex:accumulationDate before RiC-O 1.1 was released (which now defines rico:accumulationDate), and we only managed to define it as a owl:DatatypeProperty; rdfs:subPropertyOf rico:date, ex:datatypeProperty (we had to define the latter within our own schema as well)."

A priori no, we do not plan to create such properties. 

If you want to add a specific property to RiC-O for addressing local needs, you can simply extend RiC-O: create your own ontology, import RiC-O in this ontology, and then add to it the specific properties needed, simply findind a RiC-O property that could be the super-property of those specific local properties. For example, if you would really need to have a property to assert that some person is the grandfather of another one, just create a say ex:isGrandFatherOf property, with domain and range rico:Person, and specify that it is a subproperty of the OWL rico:isAncestorOf object property. 

Same if you need to define a specific class for your dataset. Define it as a subclass of rico:Thing, or of a more specific RiC-O class, subclass of rico:Thing, if you know that all the entities that would belong to this specific category in your data also belong to the upper RiC-O class. 

Hope this will help you. 

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

---

De : records_in_c...@googlegroups.com <records_in_c...@googlegroups.com> de la part de Pavel Zhelnov <pje...@gmail.com>
Envoyé : mardi 3 juin 2025 00:10
À : Records_in_Contexts_users <records_in_c...@googlegroups.com>
Objet : [Records in Contexts users] RiC-O and Linked Open Data

 

--
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 visit https://groups.google.com/d/msgid/Records_in_Contexts_users/c78d4e5d-0006-4919-9e60-63c4e41d75ddn%40googlegroups.com.

---

Merci de nous aider à préserver l'environnement en n'imprimant ce courriel et les documents joints que si nécessaire.

[Pavel Zhelnov]

Dear Florence,

This sounds very good and helpful – many thanks for your extensive response!

Pavel

--

Pavel Zhelnov

You received this message because you are subscribed to a topic in the Google Groups "Records_in_Contexts_users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/Records_in_Contexts_users/sfb6uAjV8d4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to Records_in_Context...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/Records_in_Contexts_users/PR0P264MB328913DDC50559BC482FC03ED56DA%40PR0P264MB3289.FRAP264.PROD.OUTLOOK.COM.

[CLAVAUD Florence]

Sorry for the typos in my answer... 

We would be happy to hear more about your project, when possible and if you would like.

Best regards,

Florence

---

De : records_in_c...@googlegroups.com <records_in_c...@googlegroups.com> de la part de Pavel Zhelnov <pje...@gmail.com>

Envoyé : mardi 3 juin 2025 12:00
À : Records_in_C...@googlegroups.com <Records_in_C...@googlegroups.com>
Objet : Re: [Records in Contexts users] RiC-O and Linked Open Data

 

To view this discussion visit https://groups.google.com/d/msgid/Records_in_Contexts_users/CAFr1gg7%3D7nTOOCOCGTxxZ%2BR%3DXagNF36MOEe65%3D9-q%2BhcD-j0NQ%40mail.gmail.com.

[Pavel Zhelnov]

No worries, Florence, and by all means – more information about our pilot implementation of RiC-O at the Archives of Ontario is available from its GitHub page:

https://github.com/gbad-project

We try to keep this page up to date. We are also excited about the recently released EGAD RiC resource list and aim to file a submission once we have something stable to release.

As a brief overview, our project is a collaboration between the University of Toronto’s GLAM Incubator and the Archives of Ontario. Here is a short video that introduces the team: https://youtu.be/3ZtTppHhyN0

Over the past two years, we’ve been able to assemble an end-to-end spreadsheet—to–RiC-O conversion pipeline and run our entire Authorities and Description datasets through it (producing about a million asserted triples). We had no EAC/EAD XML data to begin with, so we had to experiment. We leveraged the beautiful Richard Williamson’s Draw.io tools and our own Python code to construct RDF Mapping Language (RML) graphs. We have also established internal guidelines for URI modeling, including some provisions for an open-world URI resolver.

In terms of the infrastructure, we are experimenting with open source quadstores (e.g., Trifid, Oxigraph) and local VPS and cloud service providers. We have been exploring Sparnatural as a web frontend component. We have also been developing a suite of Visual Studio Code extensions to enable graph editing, creation, and validation. We are also exploring the interoperability between RDF and large language models (e.g., through Pydantic and JSON schemas).

Aaron Hope, Senior Archivist at the Archives of Ontario, is leading this project and is also an active member of this Google Group. We will also speak about the project at the upcoming Association of Canadian Archivists (ACA) conference in Ottawa on June 10, 2025.

As a message to the community – don’t hesitate to get in touch with us using the contacts indicated on our GitHub page.

Thank you to everyone for your amazing work!

Best regards,

Pavel

--

Pavel Zhelnov

To view this discussion visit https://groups.google.com/d/msgid/Records_in_Contexts_users/PR0P264MB3289B7D8427140F0B20A6DBAD56DA%40PR0P264MB3289.FRAP264.PROD.OUTLOOK.COM.