Appraisal in Record in Context

[Jochen Deprez]

Hello everyone,

Very exited to have discovered this new archival description standard. 

About myself: i'm a Belgian archivist-records manager who works for a regional organisation that supports local towns and cities in performing various tasks, activities and services for the public, such as their archival and records management. I'm currently looking into RiC-O, and might start implementing it in my own organisation.

While reading through the documentation, i noticed there's no description for appraisal, or did i miss it in both the RiC-CM and RiC-O standards? It is present in ISAD(G), and since it's an important aspect of archival description and recordmanagement (especially in my country), i find it wierd that it's missing somehow.

How would you reccommend we document things like appraisal? Should i just add it as an extension to RiC-O in Protégé? If yes, how do i do that?

[Richard Williamson]

Dear Jochen,

Thank you for your interest (and excitement), and welcome! Florence
Clavaud who is our guiding light on RiC-O will not be able to reply
for some days at minimum, but I will try to shed a little inferior
light, and Florence will I am sure chime in when she is back if she
wishes to add or correct something.

The key emphasis as I see it (I have been a member of EGAD/the RiC-O
team since roughly Easter this year, and using RiC for quite some time
before that; I hope at least that my perspective should not diverge
massively from a more authoritative one!) in RiC for this kind of
thing is upon the Activity/Event entity. Use of Activity/Event,
especially in the kind of context you describe, is for me one of the
most exciting, interesting, and useful aspects of RiC, but at the same
time, it is quite novel compared to earlier archival description
standards, and thus typically probably one of the ones that one will
need to fight hardest for to take into use in implementations!

In general, we could model 'Appraisal' as an Activity. Let us say that
we have a Record Set R. We could then introduce 'Appraisal of R' as an
Activity too; we could say that 'Appraisal of R' is a sub-activity of
the general Appraisal Activity by using e.g. rico:isDirectSubeventOf;
and we could relate Appraisal of R to R by for example
'isOrWasAffectedBy'. Thus, as slightly informally expressed RDF
triples:

Appraisal rdf:type Activity
R rdf:type RecordSet
'Appraisal of R' rdf:type Activity
'Appraisal of R' rico:isDirectSubeventOf Appraisal
R rico:isOrWasAffectedBy 'Appraisal of R'.

There are now all sorts of things one could do to enrich 'Appraisal of
R'. An obvious one would be 'rico:isOrWasPerformedBy'. To mirror
ISAD(G), which refers to 'information about appraisal', in the most
direct way, one would probably just use rico:generalDescription with
domain the 'Appraisal of R' activity, i.e.

'Appraisal of R' rico:generalDescription 'Something interesting...'.

But RiC, whilst fully allowing for and acknowledging as valid more
traditional usage patterns of this kind, would encourage consideration
of a different approach. Indeed, the most powerful property with
domain any Activity is 'resultsOrResultedIn'. This allows one to build
chains of events, to connect activities/events to records/record sets,
to dates, to agents, and so on; a really rich structured context. For
instance, if R contains a Record X and Appraisal of R leads to
destruction of X, we might say:

X rdf:type Record
Destruction rdf:Type Activity
'Destruction of X' rdf:Type Activity
'Destruction of X' rdf:isDirectSubeventOf Destruction
'Destruction of X' rico:affectsOrAffected X
'Appraisal of R' rico:resultsOrResultedIn 'Destruction of X'

Hope that helps a little! Just let me know if not, or if you'd like me
to elaborate upon something :-).

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/60d142ae-5f9a-4c1e-a988-844b69f8eb35n%40googlegroups.com.

[Jochen Deprez]

Dear Richard,

Thank you for your quick response! Also hoping to receive more insights from Florence Clavaud when she returns.

If i understand your response correctly, RiC sees "appraisal" as an Activity (or process), with an Event for each RecordSet related to it. This covers the event of actually destroying the Instantiations of a certain Record or RecordSet (without actually deleting the Record or RecordSet itself), resulting in a DatatypeProperty "destructionDate" with the actual date of destruction as a value. Alongside the Activity where you destroy it, you also have the Activity in which you describe when you will destroy it or keep it permanently as a separate "Archival Description" Activity.

In Flanders (Belgium), we have a law that determines that we must register metadata like the appraisal (eg. Destruct 10 years after file end date) , information classification (from the GDPR), means of  reproduction, means of access and when a file can be publically accessed. This registration occurs on the Series-level and is registered in a system provided by the government of Flanders, which runs seperately from our own record management systems. But these metadata are also applied on the File and Record level for the objects that are related to it. In an ideal situation i should be able to model this in RiC to correctly represent this reality and be able to correctly apply these concepts from Series to File and Record level. 

While the appraisal is regulated on the Series-level, the destruction obviously occurs on File or even Record level. We are recommended to do this in bulk (eg. once every year, at the start of every year). 

The question is, how exactly am i going to represent all of this correctly? I currently see the following solution:

• Applying Appraisal as an Activity for the actual destruction of files and records as described, related to an Event for each bulk destruction event, which is in turn related to the actual RecordSets, Records and Instantiations that are destroyed during a specific Event.

• Applying Appraisal as a SubActivity or SubEvent of the Activity "Archival description", or describing in the Archival description Activity that this is part of the process.

• Adding the Series-register as a Rule or Mandate, with its own Datatype Properties for the metadata it registers and which must be re-used within the ontology, alongside and related to the Laws that implement this.

• Adding my own Datatype Properties to the model to describe the year of destruction and year of public availability, etc.,  and properly relate them to the correct classes, so i can describe these things on the Series, File and Record level. In this way the model effectively becomes a recordmanagement system.

Sidenote: The majority of my descriptions will be in Dutch. So, i suppose i have to label everything correctly so the ontology recognises the values entered are in Dutch right? How do i do that? Just add a rdfs:label [language: nl] for new Classes, Datatypes and Object Properties and maybe also adding it to the existing ones while i'm at it, and/or adding a language tag to each Datatype Property for each individual / instance?

I realize now that things can get confusing and complicated really fast when doing this kind of work :) . 

Greetings,

Jochen Deprez

Op woensdag 25 september 2024 om 01:21:08 UTC+2 schreef richard.william...@gmail.com:

[Arian Rajh]

Dear Joachen, 

An appraisal is an activity (under event class), and there is a rico:history datatype property with record resource as the domain (these methods of describing appraisal and other interventions were mentioned under subtitle 2. About ric-o datatype properties at https://www.ica.org/standards/RiC/RiC-O_1-0-2.html). It depends on how you describe/model this activity and what you want to do with it as retrieved. Maybe the fourth part of the standard, when published, will refer to similar use cases. 

Kindly, 

Arian

Dr. sc. Arian Rajh, izv. prof. 

Poslano s mojeg iPhonea

24.09.2024., u 14:57, korisnik Jochen Deprez <deprez...@gmail.com> je napisao:

Hello everyone,

--

[Richard Williamson]

Dear Jochen,

Interesting! I am impressed with how quickly you have grasped the
ideas! I attach a graph in which I have attempted to model some
aspects of the situation as I understand them; I attach also the raw
XML, which can be opened in the online software https://draw.io, in
case you wish to explore it yourself. I used a library containing
shapes for RiC which I wrote some time ago, which can be imported into
draw.io; instructions for how to do it are at the following link...

https://github.com/williamsonrichard/records_in_contexts_draw_io_shape_library

...and there are also a couple of threads on this list about it, which
you can see at the following links.

https://groups.google.com/g/Records_in_Contexts_users/c/jvPTj01KmU0

https://groups.google.com/g/Records_in_Contexts_users/c/zZiEldz3hcQ

You will see that your suggestions and reflections are very apt; I
have followed them quite closely! I attach too ontology individuals
(in Manchester syntax) generated from the graph in case they are
useful (can e.g. be opened in Protégé). A few more quick comments:

1. You will see that I almost entirely use object properties; I employ
only one datatype property 'normalizedDateValue'. Use of object
properties and the Date class allows for greater flexibility; you will
see in the graph various ways in which I make use of this.

2. It is an interesting question whether destruction pertains to an
Instantiation or a Record/Record Set! As you suggest, one could
certainly formulate it at the level of Instantiation instead, and I
definitely agree that it can be useful to consider Records for which
we no longer have Instantiation. However, in this particular context,
I would probably argue that destruction does actually pertain to the
Record; the decision to destroy comes from an evaluation of the
intellectual value of the (information of the) Record, the conclusion
that we no longer need it to regard it as belonging to the archival
domain (being a Record). That does not exclude somebody at a later
point in time regarding the destruction as wrong, and wishing to refer
to the Record, only modelling the Instantiation as destroyed.

3. There is also a question of whether to use Event or the narrower
Activity for 'Appraisal of F' and similar. Purely linguistically, one
might think to choose 'Event', but I would rather focus upon the part
of the scope note of Activity which states: "Activity is specifically
used to designate purposeful human activity." I.e., even though it was
short-lasting compared to the general Activity of Appraisal, I would
still regard 'Appraisal of F' as an Activity, because it was
definitely a purposeful human activity while it lasted :-).

4. One could in principle do quite a lot of interesting and useful
things with inference here. E.g. if one used a good Time/Date ontology
in addition to RiC, one could actually infer what date '10 years after
the end date of F' is from the end date of F as expressed with respect
to that ontology.

5. With regard to Dutch, when you use strings as the values of
datatype properties, you can just add '@nl' at the end, e.g. in
Norwegian we would have 'et eller annet'@nb. Otherwise everything is
structured, so the only thing you have to choose are the IRIs for
individuals.

6. With regard to complexity, just in case anybody reading is about to
be frightened off, the point that Arian made is a very good one, thank
you Arian! Namely RiC fully allows one to just add a little free-text
note 'F to be destroyed ten years after its end date' to one's series
using some datatype property like rico:history or
rico:generalDescription, and be done with it, without use of Activity
at all! Or as in my original message, one could go as far as using an
Activity, but then just add a little free-text note to that Activity.
But I take it that you are interested in how it might be done if one
makes use of the fuller possibilities of what RiC has to offer :-).

Do let me know if I misunderstood what you took up, and/or if the
graph does not in fact correspond to what you would like to discuss!

Best wishes,
Richard

> To view this discussion on the web visit https://groups.google.com/d/msgid/Records_in_Contexts_users/28d9e089-ac4f-4917-9be6-6358f4e42890n%40googlegroups.com.

[Jochen Deprez]

Dear Richard,

Thank you for all information provided and the work you did on modelling my case in draw.io! I will surely re-use your Draw.io RiC model for my own visualisation purposes and look into the links you've posted.

It looks like an elegant solution to my problem, I would just add 2 rico:hasDestructionDate relations: One for RecordSets with RecordSetType "Series" with the regulations made in the Series-register like you modelled here, but i would add a second one for RecordSets with RecordSetType "File" where i register the actual forseen date of destruction. Then i would be able to fully comply with the law. Same goes for the other metadata that needed to be registered and applied on either the Series or File level. I will try to fully model this in Protégé and use Draw.io to visualise it. When i'm finished, i will post it on this thread. It can take me some time though, as i'm doing this with some "spare" or otherwise "lost" hours in between projects and local elections are coming in two weeks, so my time will be very limited, probably until the end of this year. 

Thank you for the compliment! It took me some time to actually grasp the concept or RiC, i've been reading through the documentation and RiC-O since past summer. I'm now just thinking about how i would take it into practice. That means i will have to "join" RiC with the laws, rules and guidelines that exist within my country. Also, This Series-register is supposed to be linked open data and is combined with a digital repository, so in time, we should be able to "join" these standards together in the future. Once the Series-register is fully operational, i will talk with the developers and see what's possible. There's a lot of potential in both systems.

The more i'm looking into it, the more i'm getting conviced that RiC could be the future for Recordmanagement and RMS systems we use. RiC has the potential to become a real paradigm shift like the ISAD(G), ISAAR(CFP), ISDF and ISDIAH-standards before it. For ease of use though, i'm hoping for the Application Guidelines will give the standard the final push it needs to fully mature. If it would be possible to develop an AtoM-like solution to make CRUD-operations (Create, Read, Update and Delete actions) less cumbersome, that would be perfect. As for now, adding indivuduals / instances in Protégé can be a bit cumbersome, lots of colleague-archivists would not be tech-savy enough to successfully use this i'm afraid. Haven't looked into GraphDB yet though, would that be a better solution for CRUD-operations? Can you make form-like inputs with that?

Kind Regards,

Jochen

Op do 26 sep 2024 om 02:51 schreef Richard Williamson <richard.william...@gmail.com>:

To view this discussion on the web visit https://groups.google.com/d/msgid/Records_in_Contexts_users/CAOapDiKAjHr_uprGHCq7aCJNxG4XzWgJgFxS8E_PjiXYzZm-bw%40mail.gmail.com.

[Jochen Deprez]

Dear Adrian,

Thank you very much for your feedback, i will be looking forward to the application guidelines. Any idea when these are supposed to be punlished?

Op wo 25 sep 2024 16:56 schreef Arian Rajh <rari...@gmail.com>:

To view this discussion on the web visit https://groups.google.com/d/msgid/Records_in_Contexts_users/5E2A3108-CC2B-4A66-9A55-A28F7E1A29B1%40gmail.com.

[CLAVAUD Florence]

Hi Jochen and Richard,

This is a very interesting example indeed.

I do not have a lot to say about the suggestions Richard made, except that this is very well done IMHO! May also be a very good source of inspiration for the FAQ in the guidelines 😉

Of course, once you start to consider and model such metadata as a graph of linked entities, you realize that this graph can be enlarged and refined 'at will', i.e. as much as necessary  - this is one of its most remarkable features. For example, we could imagine that it is in fact people - employees of the organization - who destroyed the documents, or that some software is involved in the process. We could also categorize the different activities using instances of ActivityType. We could represent more accurately the rules applied. And we could work on representing the modalities of access and use of documents; to do this in a very structured way and in accordance with what a records management system would require, it would probably be necessary to add classes to RiC-O, like ConditionsOfAccess and ConditionsOfUse (we just have datatype properties for now in RiC-O; representing those as classes is in our roadmap ;-). And, obviously, the record sets themselves result from other Activities. Etc.

I agree with the idea that appraisal  concerns Record resources, as it is about evaluating their content first. Destruction would concern both the Record Resource evaluated and it various instantiations, if it has several ones, in the broader set in which it is included. In some situations, the digital instantiations could be kept. This would of course not mean at all that the metadata that describe the deleted items do not remain available. Also, of course there may be drafts or copies of the deleted records and instantiations elsewhere. One of the challenges archivists are facing nowadays is indeed to be able to evaluate a record set, taking into account the fact that there exist elsewhere other records which are originals or copies of those records (thus having quite the same content), or instantiations of those records. We can imagine in the future that deciding what to do (for example deciding which appraisal rules can be applied to some records) may be facilitated if those  records sets can be connected to each other using relations like the ones RiC provides, based on the activities they result from. Well I am digressing 😊

And yes, it would be great if RiC can help build bridges between the world of records management and the world of archival/historical records keeping. This would be very beneficial for data exchange and interoperability, and for the general public. As far as I know, at least in France, records managers do not use ISAD(G), ISAAR(CPF) or ISDF so frequently. For many reasons, RiC might be more interesting for them. We should probably work together to make it better. There already have been some discussions between EGAD and the WG which maintains ISO 23081.

Jochen, IMHO you should not use Protégé for editing RiC-O datasets directly, but only for testing the ontology on real use cases during the first steps of a project, or for browsing or extending the ontology. Protégé is an ontology editor, not a software for producing or managing RDF individuals. If you need to produce RDF datasets and are starting from an existing RM system, you could, as a first step, try to design and apply a conversion tool for data exported from the RM system, or ask some company to do so. When you get significant amounts of RDF datasets, you will need a graph base to store, manage and query them. GraphDB is a very good one; there are other tools of the kind. You may also choose to move, in the end, to a new system that would be based on RiC, would enable archovists to esaily edit RiC-based metadata and perform activities, and would at least expose your metadata as Linked Open Data (RDF). For now, RiC is too recent a standard and dedicated complete tools based on it are rare. If you can understand French, you might have a look at the presentation that Jan Krause-Bilvin did about the docuteam software suite on September 10th during the 3rd French webinar on RiC (slides and viedo recording to be published soon).

This is only my two cents.

All the best,

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 Jochen Deprez <deprez...@gmail.com>
Envoyé : vendredi 27 septembre 2024 09:51
À : Records_in_C...@googlegroups.com
Objet : Re: [Records in Contexts users] Appraisal in Record in Context

 

To view this discussion on the web visit https://groups.google.com/d/msgid/Records_in_Contexts_users/CAE3fQCytWveM-18KF7Fe3f%2BVUcCdPs-d0X6-Sk%3DAYby%3DBKO5Zw%40mail.gmail.com.

---

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

[Jochen Deprez]

Dear Florence,

Thank you very much for the feedback. Unfortunately, my organisation doesn't allow the use of Database software for security purposes (i'm not allowed to run mySQL or even AtoM either). So if i would want to implement all of this, i will need a company to design it for us, which is also not going to happen, as my organisation will not be willing to spend that amount of money on a project based on a standard that is still so young and not fully developped yet. I may be able to convince them in the future if more concrete use cases and examples are presented.

I will eagerly be on the lookout for the Application Guidelines. My French is average, but i will certainly watch the video of the 3rd French Webinar when i'm able to do so. On which channel will it be published?

I understand that the situation in France is totally different than in Flanders. Here, the traditional ICA standards used alot more, so i think the solution for my problem lies within EAD (and trying to extend it with the metadata from the Series-register and digital repository) for the moment. As i read, there's a conversion tool for EAD to RiC already, so if i adhere to the EAD-standard as much as possible, a future migration should be possible if desired. 

Another possibility would be for me to try and "translate" the RiC-concepts into a more traditional system (more spreadsheet or MS Access-like) in order to bridge the gap. Then i can see it like this:

• Classes are Tables (so one for each class)
• Datatype Properties are attributes or columns
• The Relation Classes are used as a means to not only describe the relations, but also relate them to the actual class instances.

All that said though, i will be following the future developments of RiC, as i'm still convinced this standard is the way forwards for our sector as a whole. 

Op di 1 okt 2024 om 18:23 schreef CLAVAUD Florence <florence...@culture.gouv.fr>:

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

[Arian Rajh]

Dear Jochen,

If databases are a problem for your organization, you can try some things with the local Jena ARQ SPARQL processor, e.g., save descriptions created according to RIC and create some queries to test things. This is just an idea.

Kindly,

Arian

[CLAVAUD Florence]

Dear Jochen,

Just to react to some of your  lines below:

- I fully understand what you said about your institution not willing to fund a change of your system to move to a RiC-based one just now. You could then work on a smaller project or prototype/proof of concept one, outside of the system, just to help the head of your institution understand the benefits and what is at stake. The RiC-AG should also provide more information about these topics, and about some projects, like the one at the Amsterdam City Archives where a new system is being built. 

- about the French webinars that took place in June and September: you could for now have a look at the slides and material on the first and second one. See this message: https://groups.google.com/g/Records_in_Contexts_users/c/sH2ed6FLhWo/m/dVwsgCgqAwAJ

The slides of the 3rd webinar (which was about the RiC scene in Switzerland), and video recordings of the whole, should be available soon (I will try to publish them next week).

- In France many archival institutions, or libraries holding manuscripts and archival fonds, use EAD (and sometimes EAC) as they are compliant with the former ICA ISAD(G) and ISAAR(CPF) standards. This has been a recommendation from the central administrations for years.
At the Archives nationales de France where I am working, this has been the case since the early 2000s. Which results in a huge corpus of about 32,000 EAD finding aids (so about 11 million ISAD(G) 'units of description') and 16,000 EAC-CPF authority records, which are continuously evolving. We also have vocabularies, authority records about places, and metadata desribing records in many other formats, and many issues (silos, redundancies, quality issues, etc.), and moving to a new data-centered, hopefully RiC-based system, will take a lot of time. 

Anyway, we (I mean the team being now the Lab, which is in charge of the LOD projects here)  started to use RiC-O in 2017, and, among many other projects, we developed, with the Sparna private company, an  EAD and EAC-CPF to RiC-O (0.2) converter open source software, which is fast, reliable, powerful and can be adapted. We use it for many projects.
See the source code and documentation here: https://github.com/ArchivesNationalesFR/rico-converter.

And also this article : https://doi.org/10.1145/3583592

Let me add that we are going to develop a version 3 of RiC-O Converter just now, in order to move to RiC-O 1.0, among other features (see the issues opened on GitHub). This should be done by the end of this year I think. Do not hesitate to contact us if you have questions about this tool!

Best regards,

Florence

---

De : records_in_c...@googlegroups.com <records_in_c...@googlegroups.com> de la part de Jochen Deprez <deprez...@gmail.com>

Envoyé : jeudi 3 octobre 2024 10:04

To view this discussion on the web visit https://groups.google.com/d/msgid/Records_in_Contexts_users/CAE3fQCzTWm0u-zi%2B9pUm2-_iJ%3D0H143uvJiw%2BhNanwjowRHvgA%40mail.gmail.com.

[Jochen Deprez]

Dear Florence,

Once again, thank you very much for the detailed information provided, i will take this all into scope!

I think for now, the "classic" archival description standards will have to do. We can easily convert that into EAD and then into RiC if we think "the time has come" to make the switch. I will however, keep following this user group, experiment with it and read up on any new documentation that gets published. If I have any further questions (or use cases), i will not hesitate and contact you.

Greetings,

Jochen

Op vr 4 okt 2024 om 12:10 schreef CLAVAUD Florence <florence...@culture.gouv.fr>:

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

[Jochen Deprez]

Dear Arian,

Thanks for the tip, i will look into that!

Greetings,

Jochen

Op do 3 okt 2024 om 20:39 schreef Arian Rajh <rari...@gmail.com>:

To view this discussion on the web visit https://groups.google.com/d/msgid/Records_in_Contexts_users/958493a0-ac32-447e-9838-1d927b0d98e2n%40googlegroups.com.