New Tool: RiC-CM Nav & Modeling Playground for Records in Contexts Conceptual Model

[Matthew Damigos]

Hi all,

I would like to share with the community a new interactive web tool, named RiC-CM Nav tool, designed to simplify the navigation and practical application of the Records in Contexts Conceptual Model. The tool provides a user-friendly interface to explore the entities, attributes, and relationships within the framework, making it an essential resource for training, professional research, and understanding RiC-CM. The definitions, scope notes, and examples included in the tool are those provided in the RiC-CM v1.0 documentation.

A standout feature is the Modeling Playground, which facilitates a deeper understanding of the standard by allowing users to design and visualize their own conceptual models based on RiC-CM principles. You can explore the navigator and start experimenting with the playground at https://dlib-ionian-university.github.io/ric-cm-nav/.

Feedback and suggestions from the community are more than welcome to help improve the tool. Please feel free to share your thoughts or report any issues as we continue to develop this resource!

Thank you

[Thomas Francart]

Very cool. A super useful feature of similar browsers like the page of the CIDOC-CRM [1] is to list all properties, **including inherited ones** (in the CIDOC-CRM page, click on a class, and click on "Show all properties" next to its title).

It took me a while to understand that your navigator is actually showing the same thing, by listing inherited attributes and relations.

When listing the relations, it seems a bit misleading to list the explicit range along with all inherited ones (e.g. when the range is Thing, then all entities are listed). Maybe you could distinguish between explicit range, and inherited ones ? similarly, when listing the relations, you could distinguish between the ones explicitly attached at this level, and the inherited ones (and from which ancestor they are inherited - this is very explicit in what is shown for the attributes, but not as explicit for the display of the relations).

Similarly, on a property page, giving all inherited classes as domain and ranges is misleading. The domain of R016 has successor is not Agent or Person or Group or Mechanism or Family, etc. The domain is just Agent. Of course subclasses could be listed as well, but just as a help to browse quicker, and they should be clearly marked differently.

Kind Regards

Thomas

[1] https://cidoc-crm.org/html/cidoc_crm_v7.1.3.html

--
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/6c5f6de2-c532-4aca-9814-6a52ebe2b3a5n%40googlegroups.com.

--

Thomas Francart - SPARNA
linked data | domain ontologies | knowledge graphs
blog : blog.sparna.fr, site : sparna.fr, linkedin : fr.linkedin.com/in/thomasfrancart
tel :  +33 (0)6.71.11.25.97

[CLAVAUD Florence]

Dear Matthew and all,

Thank you, this is indeed a very interesting and useful tool.

Just for your information: EGAD has included in its roadmap the transition to a structured version (probably in XML/TEI) of the RiC-CM source file, which is currently a Word file. This is one of our priorities for this year, for several reasons, including because we want to distribute RiC-CM - in addition to a PDF version - as a website offering the same ease of navigation and exploration as the web site you released.

Best regards,

Florence Clavaud

Head of the Lab, Archives nationales de France

Chair of EGAD

---

De : records_in_c...@googlegroups.com <records_in_c...@googlegroups.com> de la part de Thomas Francart <thomas....@sparna.fr>
Envoyé : lundi 20 avril 2026 10:26
À : Records_in_C...@googlegroups.com <Records_in_C...@googlegroups.com>
Objet : Re: [Records in Contexts users] New Tool: RiC-CM Nav & Modeling Playground for Records in Contexts Conceptual Model

 

⚠ Expéditeur Externe au ministère de la Culture. Ne cliquez sur aucun lien et n'ouvrez aucune pièce jointe à moins que vous ne reconnaissiez l'expéditeur et que vous soyez sûr que le contenu est sans danger.

To view this discussion visit https://groups.google.com/d/msgid/Records_in_Contexts_users/CAPugn7XNRKHLnm_mKAxQ4rjGfkxxL2TAOY-g_K7B%2B6BBHv9WtQ%40mail.gmail.com.

---

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

[Schihin, Oliver]

Thanks a lot, that is very helpful for finding a way into RiC-CM (and RiC-O). I second Thomas’ comments.

On the playground: Why can I build the relation in the attachment, i.e. <Person> <precedes in time> <record part>? Is this an issue with the CM itself or the playground?

Best regards

Oliver

 

Von: records_in_c...@googlegroups.com <records_in_c...@googlegroups.com> Im Auftrag von Thomas Francart
Gesendet: Montag, 20. April 2026 10:26
An: Records_in_C...@googlegroups.com
Betreff: Re: [Records in Contexts users] New Tool: RiC-CM Nav & Modeling Playground for Records in Contexts Conceptual Model

 

Sie erhalten nicht häufig E-Mails von thomas....@sparna.fr. Erfahren Sie, warum dies wichtig ist

.
To view this discussion visit https://groups.google.com/d/msgid/Records_in_Contexts_users/CAPugn7XNRKHLnm_mKAxQ4rjGfkxxL2TAOY-g_K7B%2B6BBHv9WtQ%40mail.gmail.com.

[Johan Pieterse]

Florence and all,
  
That's excellent news — thank you for sharing EGAD's direction on this.
  
For what it may be worth to the discussion: we've been building OpenRiC (https://github.com/openric/service), an open-source (AGPL) Laravel + Apache Jena Fuseki service built RiC-O-native from line one.
Its most recently shipped component is a browsable, SPARQL-backed reference view of RiC-CM 1.0 - 19 entities, 42 attributes, 151 relations - deliberately surfacing the CIDOC-CRM-style declared vs.
inherited distinction on every page, so a relation with domain Agent is presented as Agent, not Agent + Person + Group + Mechanism + Family. Matthew's NavTool was a useful reference point during the
design work, and the inheritance resolver we wrote is intentionally portable if it's ever useful to him or to the wider community.
  
If the EGAD migration to a structured source is happening anyway, we'd be keen to align - both as consumers of whatever structured form you settle on (XML/TEI, a richer RDF serialization, or both) and
as a sandbox where EGAD could prototype the public-facing website experience ahead of official release. Happy to demo, share code patterns, or simply be patient.
  
Johan Pieterse
 The Archive and Heritage Group
 jo...@theahg.co.za