Draw.io shape library for Records in Contexts

[Richard Williamson]

Dear all,

As many of you may have experienced, it is often much easier for
people to work graphically with ontologies than in plain text.
Unfortunately, the existing tools that I am aware of which understand
OWL are typically not entirely satisfactory in one way or another with
regard to graph visualisation. Recently, we (Norwegian National
Archives) have been exploring possibilities, and see use of

https://draw.io

as very promising. This is a powerful and flexible, open source, graph
application, but it a priori does not understand OWL. However, I have
now created a 'shape library' for draw.io which (for my sins!)
contains (almost) the entirety of RiC:

https://github.com/williamsonrichard/records_in_contexts_draw_io_shape_library

It should hopefully be more or less trivial to use; I hope the README
file explains it, but basically one just opens up draw.io and imports
the XML file in the repository (shape library). RiC is rather large,
but one can hover over the shapes, and I think quite quickly find what
one needs and drag it into the graph canvas. This should save a lot of
time compared to creating the graph manually.

The repository contains a few examples, but I attach the pictures to
this email just to illustrate the kind of things possible. A quick
summary:

* one of the graphs illustrates some data about a record set
concerning 'Koronakommisjonen' (a commission to do with the pandemic),
and there is a colour version of this one;

* one concerns a different record set concerning a researcher's notes
on an archive from the German occupation of Norway in the second world
war (in the unlikely event anyone remembers, snippets of these two
examples were also included in plain text form in our talk at the
study day in the autumn)!

* one illustrates how a certain record (within a record set) with
certain record parts, whose metadata was originally expressed in the
standard 'Noark', can be mapped to/expressed in RiC. The symbol ⊂
means 'subproperty of' or 'subclass of'.

See the README file for more. In particular, I envision
programmatically generating formal syntax in OWL from graphs built
using this shape library, and also populating graphical templates from
formal OWL. In this way it should actually be possible for most people
in an organisation to only work graphically with RiC if they so wish,
with only a few needing to actually understand the formal details of
OWL.

We have shown these kind of graphs to quite a number of people with
different, non-technical backgrounds, who do not know anything about
RiC or OWL from before, and have had positive feedback: the graphs
seem to understandable, which is also to give a lot of credit to
everyone who has built RiC itself!

I would be very happy for any feedback/discussion, or to hear of any
bugs/feature requests! In particular, if there are other ways of
organising the shapes that people would prefer, just let me know.

Best wishes,
Richard

[Florence Clavaud]

Hi Richard,

This is a good idea!

I have being using draw.io for years now, to illustrate presentations on RiC (some of these draw.io diagrams are actually stored in the GitHub repo on RiC-O). 

And I fully agree; draw.io is a simple tool, and it is helpful to explain what RiC or RiC-O is in fact, and how you describe records and of their contexts using RiC.

So this library can be very useful to spare time when you need to prepare such diagrams.

I think having the Relation classes and properties in this library would be good too. I do not have time for now to do so, but would be happy to contribute.

The directions you mention are also very interesting ideas.

IMHO, this tool should be mentioned in the list of resources about RiC I had suggested we create and share (I am currently working on a simple Google sheet, just need a few more days before coming back to it on this list).

Best regards,

Florence Clavaud

[Arian Rajh]

Hi Florence and Richard,

did you try Web Vowl editor (https://service.tib.eu/webvowl/)? 

I have used it to clarify some concepts for my own purposes.

Kind regards,

Arian

[Richard Williamson]

Hi Arian,

Grand that you have used the Web VOWL editor! Yes, we have tried it, I
think it is the best off-the-shelf visualiser that I have seen.
However, it does not handle individuals, which means that its scope is
quite limited; it cannot create the kind of diagrams I attached, for
instance. As far as I know, the lack of support for individuals is
also the case for the commercial product Grafo...

https://gra.fo/

...which builds upon it.

In addition, I would remark that, at least at the time of writing, I
think no generative tool will be able to create something as
aesthetically pleasing as something arranged manually. Not to say that
the diagrams I attached are any artistic masterpieces, but somebody
with an eye for it could create something quite good in draw.io :-).
More generally, there are lots of little ways in which one might wish
to tweak the visuals/graphical semantics in practise, as I do in some
of the attached figures (e.g. the one mapping part of Noark to RiC),
whereas with a generative tool one is locked into a particular
representation.

In addition, a key need for us is to be able to edit the graphs; this
was very buggy when I tried Web VOWL, though I presume that it works
in Grafo.

All that said, draw.io, as I wrote initially, is probably not suited
for more 'spectacular' graphs with lots of arrows and nodes (all
record sets with a certain creator, or whatever), or at least one
would need to build something on top of its APIs. I would like to try
to do something in Cytoscape.js (which Web VOWL is built upon)...

https://js.cytoscape.org/

...for this with RiC, e.g. something like this graph which also has
search and localisation functionality...

http://www.wineandcheesemap.com/

...but have not found the time yet alas; also it is not really my
specialty. If anyone likes this kind of frontend programming and would
like to experiment with such a tool, I at least would be very
interested in it!

Best wishes,
Richard

> --
> 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/ffd2186b-e92c-440b-a72b-e88f633ed553n%40googlegroups.com.

[Richard Williamson]

Hi Florence,

Thank you very much for the feedback, great to hear that you use and
agree regarding draw.io, and that the directions sound promising!

I would be happy to add the Relation classes/object properties as soon
as time allows, if nobody beats me to it :-).

I would be happy for it to be added to the list of tools!

Best wishes,
Richard

> --
> 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/2556e05f-ddbe-499b-b5eb-6f13e55a94f8n%40googlegroups.com.

[Hope, Aaron (MPBSD)]

Hello Richard,

Thank you for sharing this tool, which seems very useful indeed! I had a go at creating a basic graph for the records of a public inquiry held at the Archives of Ontario, closely following your Koronakommisjonen as an exemplar. I attach the results (you may spot some errors!).

I think non-technical tools like this will certainly help with the adoption of RiC in the archives community.

Cheers,
Aaron


Aaron Hope, PhD | Senior Archivist | Archives of Ontario
134 Ian Macdonald Blvd. | Toronto ON M7A 2C5
aaron...@ontario.ca | http://www.archives.gov.on.ca/

-----Original Message-----
From: records_in_c...@googlegroups.com <records_in_c...@googlegroups.com> On Behalf Of Richard Williamson
Sent: March 14, 2024 9:21 AM
To: Records_in_C...@googlegroups.com
Subject: [Records in Contexts users] Draw.io shape library for Records in Contexts

CAUTION -- EXTERNAL E-MAIL - Do not click links or open attachments unless you recognize the sender.

Dear all,

As many of you may have experienced, it is often much easier for people to work graphically with ontologies than in plain text.
Unfortunately, the existing tools that I am aware of which understand OWL are typically not entirely satisfactory in one way or another with regard to graph visualisation. Recently, we (Norwegian National
Archives) have been exploring possibilities, and see use of

https://draw.io/

as very promising. This is a powerful and flexible, open source, graph application, but it a priori does not understand OWL. However, I have now created a 'shape library' for draw.io which (for my sins!) contains (almost) the entirety of RiC:

https://github.com/williamsonrichard/records_in_contexts_draw_io_shape_library

It should hopefully be more or less trivial to use; I hope the README file explains it, but basically one just opens up draw.io and imports the XML file in the repository (shape library). RiC is rather large, but one can hover over the shapes, and I think quite quickly find what one needs and drag it into the graph canvas. This should save a lot of time compared to creating the graph manually.

The repository contains a few examples, but I attach the pictures to this email just to illustrate the kind of things possible. A quick
summary:

* one of the graphs illustrates some data about a record set concerning 'Koronakommisjonen' (a commission to do with the pandemic), and there is a colour version of this one;

* one concerns a different record set concerning a researcher's notes on an archive from the German occupation of Norway in the second world war (in the unlikely event anyone remembers, snippets of these two examples were also included in plain text form in our talk at the study day in the autumn)!

* one illustrates how a certain record (within a record set) with certain record parts, whose metadata was originally expressed in the standard 'Noark', can be mapped to/expressed in RiC. The symbol ⊂ means 'subproperty of' or 'subclass of'.

See the README file for more. In particular, I envision programmatically generating formal syntax in OWL from graphs built using this shape library, and also populating graphical templates from formal OWL. In this way it should actually be possible for most people in an organisation to only work graphically with RiC if they so wish, with only a few needing to actually understand the formal details of OWL.

We have shown these kind of graphs to quite a number of people with different, non-technical backgrounds, who do not know anything about RiC or OWL from before, and have had positive feedback: the graphs seem to understandable, which is also to give a lot of credit to everyone who has built RiC itself!

I would be very happy for any feedback/discussion, or to hear of any bugs/feature requests! In particular, if there are other ways of organising the shapes that people would prefer, just let me know.

Best wishes,
Richard

--
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/CAOapDiKeJLo5G1EDuMmPhxnLNvoLch0CHhQjz%2Bh%2BEDR4_CCbEA%40mail.gmail.com.

[Arian Rajh]

Dear Richard,

I agree with you. I used WebVowl to clarify how the classes are linked and found it nice and helpful. Perhaps a possible solution would be to have some open visualization platform and incorporate it into archival management solutions that work with RIC on the levels of national archives projects or commercial solutions (like, an example from another subdomain, using RODA for some European national digital preservation systems)?

Kindly, 
Arian

[CLAVAUD Florence]

Hi Richard, Aaron and Arian, and all,

As you said draw.io enables to represent parts of the conceptual model (or of any other one), of the ontology (or of any ontology), and also graphs of individuals, including from scratch. Which is useful particularly when you want to start from data that are not RDF/RiC-O ones, or to make diagrams about fictitious, partially fictitious, or simplified, examples. Therefore you can choose what you will show or not (among all the nodes and edges forming a graph of entities). I also like the fact that the source file produced for each diagram is encoded in XML, so that you can modify it (using the Draw.io interface) and share it, then use it to export the diagram in many formats (including as images of course, and also SVG).

I think such a simple (though functionnally limited), and quite user-friendly editor, that you can also both use online or install locally, is useful for testing, thinking, teaching, etc.

Which does not mean that WebOWL is not great. They are very different and do not address the same needs.

In case somebody here would like to reuse them: in order to generate the 'RiC-CM overview' diagram, which is one of the draw.io diagrams in the GitHub repo on RiC-O (and the only one using RiC 1.0 in this repo for now; see https://github.com/ICA-EGAD/RiC-O/tree/master/diagrams/diagrams_v1-0/RiC-CM-overview), we - EGAD - had chosen some colors to be used for the background of the shapes of the entities displayed - simple rounded rectangles there. 

These colors are listed below. The list is not complete. And obviously this is just information, not at all advice, and even less a recommendation 😊.

We also can commit this list to the RiC-O repo.

 

Entity	Hex	RGB
Thing	FBD5B5	R251, G213, B181
Record Resource	DAEEF3	R218, G238, B243
Agent	E5DFEC	R229, G223, B236
Group	C6D9F1	R198, G217, B241
Event	FFFAA0	R255, G250, B160
Rule	EAF1DD	R234, G241, B221
Date	DDD9C3	R221, G217, B195
Place	FAA0A0	R250, G160, B160
Instantiation	F5DEB3	R245, G222, B179

 

Best,

Florence

---

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

[Richard Williamson]

Hello Aaron,

Wow, fantastic! Really like this, it's great that you took the
initiative to do it! As a side note, I find it fascinating that there
is so much 'structure' in common between your example and ours (one of
my colleagues, Trine Kruse, who is also on this mailing list, has been
working closely with me on them :-)) despite there being two different
countries involved. This just shows the great potential for
international cooperation and the power and importance of
interoperability that standards like RiC can enable. It also makes me
all the more keen to pursue the idea of templates in draw.io that can
be programmatically filled in!

Best wishes and thanks very much again for this,
Richard

On Fri, Mar 15, 2024 at 9:57 PM 'Hope, Aaron (MPBSD)' via
Records_in_Contexts_users <Records_in_C...@googlegroups.com>
wrote:

> To view this discussion on the web visit https://groups.google.com/d/msgid/Records_in_Contexts_users/YT2PR01MB942940A0042739DCE22A6F68F9282%40YT2PR01MB9429.CANPRD01.PROD.OUTLOOK.COM.

[Richard Williamson]

Dear Arian,

That sounds like a great use of WebVOWL! I like your suggestion too! A
lot of work to reach that point no doubt, but it seems like a fine
goal!

Best wishes,
Richard

> To view this discussion on the web visit https://groups.google.com/d/msgid/Records_in_Contexts_users/04e966f2-a4b0-404c-8d21-9a96d890b467n%40googlegroups.com.

[Hope, Aaron (MPBSD)]

Hello,

 

I wonder if anyone can help clear up some confusion I have about the relationship between a Record Set and an Instantiation. I understand that a Record or Record Part must have at least one Instantiation, and I have read the note in RiC-CM (section 2.2.2) about how certain Record Sets (such as a bound volume or a digital file containing multiple Records) can have an Instantiation, but it seems as though most Record Sets will not since they are intellectual groupings of Records rather than physical ones. I also note that the class rico:RecordSet does not have any object properties that would link it to the class rico:Instantiation (though the super-class Record Resource does).

 

My question, then, is where or how to capture information about the physical description (extent and medium in ISAD(G) terms) of a Record Set that is a complete fonds. In the particular case I am thinking of, only a fonds-level description exists because the records have not been fully processed. However, the question would apply even if series and files had been arranged and described below the fonds.

 

If details about extents and media are only to be found in descriptions of Instantiations of Records and Record Parts, how can we obtain a higher-level view of this information?

 

I am sure there is an easy answer to these questions – just not one I am familiar with yet!

 

Many thanks,

Aaron Hope

[CLAVAUD Florence]

Dear Aaron,

As rico:RecordSet is as subclass of rico:RecordResource (like rico:Record and rico:RecordPart), any instance of a rico:RecordSet is also a rico:RecordResource.

So you can use, to connect a Record Set to an Instantiation, rico:hasOrHadInstantiation, which has domain rico:RecordResource.

There also are two subproperties of rico:hasOrHadInstantiation that you can use just the same way.

All the best,

Florence Clavaud

---

De : 'Hope, Aaron (MPBSD)' via Records_in_Contexts_users <Records_in_C...@googlegroups.com>
Envoyé : mercredi 20 mars 2024 19:13
À : Records_in_C...@googlegroups.com
Objet : [Records in Contexts users] Novice question about Record Sets and Instantiations

 

--

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/YT2PR01MB94293933892C6C49DC0FED25F9332%40YT2PR01MB9429.CANPRD01.PROD.OUTLOOK.COM.

[Hope, Aaron (MPBSD)]

Dear Florence,

 

Thank you for your answer – the fact that a subclass can make use of the object properties of its superclasses is an important, if obvious in hindsight, realization!

 

But I suppose it would normally make more sense to use the datatype property rico:recordResourceExtent (or the class alternative) to express the ISAD(G) extent and media of a fonds-level Record Set, rather than multiple Instantiations, correct?

 

Thanks again,

Aaron

 

From: records_in_c...@googlegroups.com <records_in_c...@googlegroups.com> On Behalf Of CLAVAUD Florence
Sent: March 21, 2024 12:57 PM
To: Records_in_C...@googlegroups.com
Subject: [Records in Contexts users] RE: Novice question about Record Sets and Instantiations

 

CAUTION -- EXTERNAL E-MAIL - Do not click links or open attachments unless you recognize the sender.

Dear Aaron,

To view this discussion on the web visit https://groups.google.com/d/msgid/Records_in_Contexts_users/e4c06323a6ef41b4a7e55e7497360673%40culture.gouv.fr.

[CLAVAUD Florence]

Hi Aaron,

Yes you can use rico:recordResourceExtent (or the class) to provide details about the quantity of information content that the record resource conveys.

The specification of the property in RiC-O is the folllowing; it includes examples (the same as for RiC-CM A35 attribute):

If you want to indicate e.g. how many linear meters or pages you have, as these are characteristics of aninstantiation of the record resource, use rico:Instantiation and its rico:instantiationExtent property. You also can use rico:carrierExtent to qualify the instantiation.

I hope this will help you.

Best regards,

Florence

---

De : 'Hope, Aaron (MPBSD)' via Records_in_Contexts_users <Records_in_C...@googlegroups.com>

Envoyé : vendredi 22 mars 2024 01:19
À : Records_in_C...@googlegroups.com
Objet : [Records in Contexts users] RE: Novice question about Record Sets and Instantiations

 

To view this discussion on the web visit https://groups.google.com/d/msgid/Records_in_Contexts_users/YT2PR01MB94298F6B5163FD355CB3B897F9312%40YT2PR01MB9429.CANPRD01.PROD.OUTLOOK.COM.

[Arian Rajh]

Dear Richard,

I have also tried GraphDB, which enables the upload of files with descriptions and their visualizations, as well as making SPARQL queries upon uploaded files. I'm working on something related to visualizations and queries with my students - I'll send some results when they are done and published. I was also thinking of using AI to generate SPARQL queries from natural languages - I tracked this idea from some more general articles that are almost 20 years old   ( e.g., Bernstein, A.; Kaufmann, E.; Kaiser, C. (2005). Querying the Semantic Web with Ginseng: a Guided Input Natural Language Search Engine. In 15th Workshop on Information Technologies and Systems, Las Vegas, 11-12.12.2005.; or more recent  Soru, T.; Marx, E.; Moussalem, D.; Publio, G; Valdestilhas, A.; Esteves, D.; Neto, C. B. (2017). SPARQL as a Foreign Language. Poster presented at  SEMANTiCS2017 conference, Amsterdam 11-14.09.2017). So, it is nothing new, but it appears that in the archival domain, as well as in languages other than English, there is a lack of established practices and guidelines regarding the issue. Work that could be done in this area - and I am thinking about something like this - is to create triplestores using RIC and linked data-harmonized descriptions and then to create AI tools for converting users' natural language queries to SPARQL queries (normalized query structures) in order to enable very unpredictable retrievals which could solve a very old archival problem of "archival futurology" (Hans Booms).  Looks like RIC+linked data+AI could provide us with a new kind of flexibility. 

Kind regards,

Arian

Dana petak, 15. ožujka 2024. u 21:56:45 UTC+1 korisnik richard.william...@gmail.com napisao je:

[CLAVAUD Florence]

Yes I agree with such a general idea (we are thinking of such a thing here) ; also, there are other experiments of the kind in other cultural communities.

 

Best,

 

Florence

 

De : records_in_c...@googlegroups.com <records_in_c...@googlegroups.com> De la part de Arian Rajh
Envoyé : vendredi 22 mars 2024 22:52
À : Records_in_Contexts_users <Records_in_C...@googlegroups.com>
Objet : Re: [Records in Contexts users] Re: Draw.io shape library for Records in Contexts

To view this discussion on the web visit https://groups.google.com/d/msgid/Records_in_Contexts_users/7a2b863f-b40b-4f2e-80c0-cfae5d784546n%40googlegroups.com.

[Hope, Aaron (MPBSD)]

Hello,

 

A couple more novice questions, if you don’t mind:

 

1. What is the class implementation of RiC-A07 Classification? For example, in the simple use case of applying Library of Congress subject terms to a Record Resource, it would seem that a class would be more appropriate than the datatype property rico:classification. Is the Class rico:Concept the best option for this purpose?
2. How can one best model the source of information for either an Agent’s history or a Record Resource’s scope and content? There doesn’t seem to be a dedicated source of information datatype property or object property (and in any case, the history and scope and content are literals).

 

Thanks for any advice!

 

Aaron Hope

 

[Richard Williamson]

Dear Arian,

Just to second Florence's reply, thank you very much for your thoughts
and links! I'd be very interested to hear about the results you
mention once you have them :-)!

Best wishes,
Richard

> To view this discussion on the web visit https://groups.google.com/d/msgid/Records_in_Contexts_users/7a2b863f-b40b-4f2e-80c0-cfae5d784546n%40googlegroups.com.

[Arian Rajh]

Dear Richard, 

Yes, of course, I'll gladly share the results. The RIC exercise was conducted with my BA students of the course Archival arrangement and description at the Faculty of humanities and social sciences at Zagreb University. It aimed to teach archival description-related subjects to the attendees and link the descriptions students provided together by using the Records in Contexts (RIC) standard, RDF Turtle standard, and a graph database. It spanned four to five weeks, during which students had to create the archival description of an exemplary records aggregation provided by the Faculty Archives as ttl files  (Jaroslav Sidak's papers; he was a historian). After that, I created a set of SPARQL queries to retrieve information that was not obvious from separate descriptions, and this was fun to see. This exercise aimed to examine the potential of RIC and linked data technologies to facilitate collaboration among students, reduce the description-related work through decentralization, enable re-using and linking descriptions, and visualize results. We had some difficulties due to the RIC-O web page being migrated, but we have used the GitHub page and RIC-CM. The paper should be published in November, and I'll send a link to the open-access publication journal. 

 

Kind regards,

Arian

[Florence Clavaud]

Hi Arian,

This sounds very interesting, and it will be great if you can notify the list when this article is published.

I also haven't forgotten this list of resources on RiC (projects, data sets, tools, articles) which could be built collaboratively shared; some news soon.

Regarding RiC-O, I am sorry that things are slow about making it available via its IRI on the ICA website. I hope we can do this in April with the company that hosts the ICA website. 

Meanwhile, I think you understood that you can easily download the ontology thanks to the release (https://github.com/ICA-EGAD/RiC-O/releases/tag/v1.0), then use an ontology editor, like Protégé Desktop, which is easy to install, to consult it. The HTML documentation that is available in the release will be the same as that which will be accessible online in a few weeks.
Once the release has been downloaded and unzipped, simply open the 'RiC-O_1-0_documentation.html' file that you will find in the 'RiC-O-1.0\ontology\current-version\HTML_view' subfolder in a browser, and you will access all RiC-O content as a human, and be able to read the specifications of each component.

You are right, the visual graphs generated by GraphDB are great and help understand what in fact the data you produce are (a graph of entities). There are  a few GraphDB screenshots in the RiC-O examples folder (and; thus, in the release).

All the best,

Florence

[Arian Rajh]

Dear Florence, dear all,

 Thank you for the useful examples. Is there an example describing a motion picture/film record resource anywhere? 

RiC-O examples folder (and; thus, in the release).

All the best,

According to some archival ontologies (ARKIVO, ArDo, ArCo), the film record resource is described using a BIBO or a separate class or subclass of the audiovisual document. According to RIC-O, it seems proper to me to use the ContentType class because films are record resources of the same level as cartographic images, recorded words, and texts. But, what would be the best way to note that this is a film, a specific content type? One way that I can think of (in ttl file) is to describe a film (e.g., Sounds of music)  as a record in the first node, then in the second node to describe (select, choose) its specific content type, and finally, to link the content type node to the record node using the "isContentTypeOf" object property. Is there a simpler way? 

 Kindly,

Arian

[Florence Clavaud]

Dear Arian,

I would do as you suggest: use the rico:hasContentOfType object property, with target an instance of  rico:ContentType (the class that corresponds to RiC-CM A10 Content Type attribute). Or, use the rico:isContentTypeOf inverse object property to link the Content type to the Record.

You could easily create such an instance of rico:ContentType, which would enable you to reuse it for describing other films.

Or, if you don't want to do so, use a concept of a SKOS vocabulary, e.g. a local vocabulary you would have, or another publicly available vocabulary, perhaps a national one; or else, just as an example among other possibilities, the Library of Congress Content Types vocabulary (http://id.loc.gov/vocabulary/contentTypes), where you can find this: http://id.loc.gov/vocabulary/contentTypes/tdi (2D moving image).

Note that if you do this, as RiC-O is a OWL/RDFS ontology, most of RDF triplestores (at least those which have an RDFS inference engine) would infer, from your data and the ontology, that the SKOS concept you have used is an instance of rico:ContentType.

You could also simply use the rico:type datatype property, which would enable you to store a litteral for the content type -  instead of linking the Record to an entity that would be explicitly or by inference defined as an instance of rico:ContentType class.

As concerns RiC-O examples describing film record resources: you are right, for now in the RiC-O repository on GitHub, there is no such example. Some audio recordings are mentioned, as parts of instantiations of record sets constituting interviews, in the dataset that describes records kept by the University of Strathclyde Archives.

The Memobase portal aggregates descriptions of many films. See for example this one: https://memobase.ch/fr/object/apf-001-1217. If you download the JSON file from this HTML page, you will find an example of a description, but neither rico:ContentType nor rico:type are used there. You could contact the Memobase project team in order to know more about their model.

Hope this helps you!

Best,

Florence

[Arian Rajh]

Dear Florence, yes, indeed, thank you,

Arian

[Florence Clavaud]

Hi Aaron,

1. 

If you want to connect a Record Resource to a subject term from the LCSH vocabulary, IMHO you could use rico:hasOrHadSubject + such a concept. In RiC-O this property has range rico:Thing, as any thing in fact can be the subject of a Record Resource.

rico:classification (or RiC-CM A07 Classification attribute), is closer to the concept of classification in libraries (thus, for example, to the LCC -  http://id.loc.gov/authorities/classification), or to the 'file plan' concept.

You're right, there is no specific class to represent this in RiC-O. And we should probably think of adding a class. I note this.

2. 

Yes rico:history is a datatype property, with range a Literal; however you also have rico:Event and, if your metadata system is ready to implement events, you could consider moving from rico:history to a series of rico:Event, that you can connect to the Agent (or to any Thing that has a history) using rico:isOrWasAffectedBy.

rico:scopeAndContent, is also a datatype property, which has domain Record Resource, and is usually used (in its well-known previous ISAD(G) or EAD form at least) to specify the "scope (such as, time periods, geography) and content, (such as
documentary forms, subject matter, administrative processes) of the unit of description"  - I am quoting ISAD(G) 2nd edition.

If you do not want to store this as discourse, you could use rico:hasOrHadSubject (or a subproperty) + any rico:Thing to represent the scope or subject matter of the record resource; rico:hasDocumentaryFormType (of the other properties related to documentary form type, defined with domain RecordSet) + a rico:DocumentaryFormType; rico:documents + an Activity to represent the activities from which the record resource results.

Well this would not really help you to store the source of information used, which is what you wanted to do.

For now, we do not have included in RiC-O any entity or pattern enabling to easily manage (so, for example, provide information about the source of) the metadata at the level of granularity you have in mind. On other words, RiC is about describing records, not about managing the description of records.

You just can use rico:Record to represent the description of another RecordResource, as a whole. 

Besides, in RiC-O 1.0, we do not have some rico:hasSource property to connect such a Record Resource to a source of information (this we must fix ASAP, I will open an issue on this).

We also have a rico:isEvidencedBy object property, with domain rico:Relation only. Relation classes can also be assigned a certainty, a state, and of course a date, a description, etc.

This topic is close to the one we had started to discuss there: https://github.com/ICA-EGAD/RiC-O/issues/56, and on which we will also work this year.

By the way, it seems that the W3C is moving forward to a full specification of what was called RDF-star. See for example https://www.w3.org/TR/rdf12-concepts/#dfn-triple-term (in a working draft dated March 2024), that defines 'triple terms'. Well, there is nothing there about OWL.

My two cents...

Best,

Florence Clavaud
Member of ICA/EGAD, lead of RiC-O development team

[Hope, Aaron (MPBSD)]

Hello Florence,

 

Thank you very much for your helpful responses to my questions – I really appreciate your guidance. I’m also glad that you’ve taken note of the possible need for a class to represent subjects and an object property like rico:hasSource to link a record resource to a source of information.

 

As I continue working my way through the data mapping process, another question that has come up concerns parallel and variant names of agents.  Where do you see RiC-O modelling ISAAR-CPF 5.1.3 (parallel forms of name) and 5.1.5 (other forms of name)? Would these names become separate instances of rico:AgentName, perhaps using rico:wasUsedFromDate and rico:wasUsedToDate as well as rico:generalDescription to provide explanation?

 

Thanks again,

Aaron

 

From: records_in_c...@googlegroups.com <records_in_c...@googlegroups.com> On Behalf Of Florence Clavaud
Sent: April 11, 2024 11:59 AM
To: Records_in_Contexts_users <Records_in_C...@googlegroups.com>
Subject: [Records in Contexts users] Re: Subject classification and sources of information

 

CAUTION -- EXTERNAL E-MAIL - Do not click links or open attachments unless you recognize the sender.

Hi Aaron,

--

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/70209434-00b5-4fc2-8ea8-2bafa9831f73n%40googlegroups.com.

[CLAVAUD Florence]

Dear Aaron,

Yes, exactly. With the rico:hasOrHadAgentName object property.

RiC-O does  not have a NameType class for now, but you could use rico:type (the datatype property) to store the type of the name if needed.

Or of course extend RiC-O for this need.

Another more complex method than rico:wasUsedFromDate and rico:wasUsedToDate, for recording the date when a name was used, is to use the n-ary AppellationRelation class. In addition to its rico:generalDescription and dates, you also can qualify the relation using relationCertainty, relationState, and relationSource + a litteral (or use rico:isEvidencedBy + a RecordResource to link the relation to a record).

All the best,

Florence

---

De : 'Hope, Aaron (MPBSD)' via Records_in_Contexts_users <Records_in_C...@googlegroups.com>

Envoyé : mardi 16 avril 2024 20:49
À : Records_in_C...@googlegroups.com
Objet : [Records in Contexts users] Parallel and variant names

 

To view this discussion on the web visit https://groups.google.com/d/msgid/Records_in_Contexts_users/YT2PR01MB9429B0528A369608B76CFDBDF9082%40YT2PR01MB9429.CANPRD01.PROD.OUTLOOK.COM.