Add a hasDigitalInstantiation object property

[florenceclavaud]

This would be a subproperty of hasInstantiation, and would be useful, for example, if you have to convert XML/EAD finding aids to RiC-O data sets, whenever you have to precisely express the meaning of dao, daogrp or daoset elements (depending on which version of EAD you are using). Also add the inverse object property of course.

[florenceclavaud]

We could also think of adding a hasAnalogueInstantiation.

[ivozandhuis]

Wouldn't we be able to model the analogue/digital-ness as a property of the Instantiation?

[florenceclavaud]

Yes we can, adding some data properties to the Instantiation (this is what we are doing for now at the AnF, and we will continue to describe the instantiations). The idea here would be to have a precise object property, that would enable to distinguish the relations to analogue and those to digital instantiations. Apart from the fact that EAD, which is widely used, provides an XML element to declare a digital instantation of a record resource, and that we should IMHO try to facilitate the path from EAD to RiC-O, it would be very 'functional' a property when you need to design an interface that would handle these digital instantiations properly, or that would enable to query only the digital instantiations, for example.

[williamsonrichard]

I like the idea of being able to refer explicitly to digital and analogue instantiations! There are maybe a few things to consider:

1. Would it be worth going further and introducing DigitalInstantiation and AnalogueInstantiation as sub-classes of Instantiation, and let these be the range of hasDigitalInstantiation and hasAnalogueInstantiation? We are currently doing exactly this. This allows the restriction of various object properties to one or the other if they only make sense in that context.
2. It might be argued that being digital or analogue is something that actually conceptually is relevant at record set level, not only instantiation level, i.e. introduce DigitalRecordSet and AnalogueRecordSet as sub-classes of RecordSet (and similarly for other variations of RecordResource, or at least some of them). We currently are making this distinction. Especially it might be argued to be important to be able to refer to record sets that were created digitally. One then will need careful guidelines as to when it is appropriate to use these various possibilities, though.
3. Related to the previous point, there are various interesting cases around 'hybrid' record sets for instance. We have currently introduced HybridRecordSet as a sub-class of RecordSets as well, and introduced object properties 'hasDigitalPart' and 'hasAnaloguePart' with range DigitalRecordSet and AnalogueRecordSet respectively. There are no doubt several ways to do this and several other such cases.

[florenceclavaud]

Hi @williamsonrichard, defining such subclasses of Instantiation is an interesting idea, though I would rather tend not to do so now (I mean in RiC-O 1.0). A fortiori, I would say the same for Record Set or any kind of Record Resource - we will not do what you suggest now. It is just because, again, we still have a lot to do in RiC-O 1.0 and do not want to add too much to the current work. I would keep the idea for the next version of the ontology. However, I would like to know what everybody here thinks of this.

Meanwhile, RiC-O can be extended, just as you did.

And you can also use the existing hasRepresentationType object property + an instance of RepresentationType class (using for example, a concept from a vocabulary) to qualify instantiations as being analogue, digital, etc.

[williamsonrichard]

Thank you for the reply! Completely understable that it would be too much to do this in RiC-O 1.0 :-). I too would be very interested to hear (for the future) what others think of this!

Meanwhile, RiC-O can be extended, just as you did.

Absolutely; as I think we have touched on in earlier conversations, I suppose there is a balance between room for extension and taking into RiC-O concepts which are common enough/central enough amongst archival institutions to be valuable to have a common semantics for (i.e. taken into RiC-O). I myself am not entirely clear in this case exactly where the dividing line is, but I think for example that where it is not entirely obvious how to model (e.g. hybrid archives), it could be very beneficial to have a canonical choice made in RiC-O.

And you can also use the existing hasRepresentationType object property + an instance of RepresentationType class (using for example, a concept from a vocabulary) to qualify instantiations as being analogue, digital, primary, etc.

This is indeed a possibility, thank you! My feeling at the present time is that the division into analogue/digital/hybrid and so on is more fundamental archive-theoretically than that of representation type, perhaps especially, as in 2. of my comment above, when it comes to the origins of the archive. Representation type seems a touch different in emphasis, perhaps closer in intention to something like 'communication medium': acoustic, electric (confusingly, both of these can be both 'analogue' and 'digital' but in a signal processing sense), and so on. E.g. an LP record could have representation type 'analogue acoustic', carrier type 'vinyl phonograph' and content type 'classical music recording', for instance. Whereas the fact that an archive is digital in origin typically refers to software, implying specific archive-theoretic concerns; but I am open to other opinions around this, there is definitely some overlap too!

[florenceclavaud]

Absolutely; as I think we have touched on in earlier conversations, I suppose there is a balance between room for extension and taking into RiC-O concepts which are common enough/central enough amongst archival institutions to be valuable to have a common semantics for (i.e. taken into RiC-O). I myself am not entirely clear in this case exactly where the dividing line is, but I think for example that where it is not entirely obvious how to model (e.g. hybrid archives), it could be very beneficial to have a canonical choice made in RiC-O.

Yes I agree on providing a canonical choice for modeling Record Resources and Instantiations in RiC-O more accurately. This would be a complex, but interesting purpose and the outcome would be very useful. We should definitely work on this after RiC-O 1.0. Just at the same time when we are hopefully also going to work with the PREMIS editorial committee in order to see how exactly we can articulate the two ontologies. This said, my first thought would be to use these qualifiers (digital, analogue, and hybrid for a Record Set) only for Instantiation, as a Record Resource is a purely intellectual object. I also had in mind a hasOrHadPrimaryInstantiation property, or something of the kind, in order to distinguish the first Instantiation produced to inscribe the Record, be it digital or analogue. Maybe both could be combined (for example, a BornDigitalRecord or BornDigitalRecordSet class being equivalent to the group of Records or Record Sets that have/had a primary instantiation that is digital).

This is indeed a possibility, thank you! My feeling at the present time is that the division into analogue/digital/hybrid and so on is more fundamental archive-theoretically than that of representation type, perhaps especially, as in 2. of my comment above, when it comes to the origins of the archive. Representation type seems a touch different in emphasis, perhaps closer in intention to something like 'communication medium': acoustic, electric (confusingly, both of these can be both 'analogue' and 'digital' but in a signal processing sense), and so on. E.g. an LP record could have representation type 'analogue acoustic', carrier type 'vinyl phonograph' and content type 'classical music recording', for instance. Whereas the fact that an archive is digital in origin typically refers to software, implying specific archive-theoretic concerns; but I am open to other opinions around this, there is definitely some overlap too!

Yes, I agree that using a vocabulary for this is not optimal, and also about the meaning of Representation Type. This was just a suggestion if somebody wants to use RiC-O only, without extending it!

[williamsonrichard]

Great!

This said, my first thought would be to use these qualifiers (digital, analogue, and hybrid for a Record Set) only for Instantiation, as a Record Resource is a purely intellectual object. I also had in mind a hasOrHadPrimaryInstantiation property, or something of the kind, in order to distinguish the first Instantiation produced to inscribe the Record, be it digital or analogue. Maybe both could be combined (for example, a BornDigitalRecord or BornDigitalRecordSet class being equivalent to the group of Records or Record Sets that have/had a primary instantiation that is digital).

Very interesting, thanks! I can definitely see the argument for regarding a Record Resource as a purely intellectual object; I look forward to further elaborations upon the record resource vs instantiation distinctions!

[florenceclavaud]

We (EGAD) just have decided to rename rico:hasInstantiation to 'hasOrHadInstantiation' in RiC-CM 1.0, and same for rico:hasDerivedInstantiation.

Rationale: in some situations, it may be useful or necessary to connect a record resource to an instantiation (or an instantiation to a derived instantiation) that no longer exists or or has been lost, when this target is worth describing in order to document the history of the resources concerned, and some of its characteristics are known from some source, like an old finding aid.

So the idea would be, for now:

• to update RiC-O accordingly
• to add two subproperties to the renamed properties, i.e. hasOrHadDigitalInstantiation and hasOrHadAnalogInstantiation (same for hasOrHadDerivedInstantiation).

And we can move forward from this basis after releasing RiC-O 1.0.

What do you think everybody?

BTW, can somebody there confirm that the term 'analog' is the good one in English (above I have used 'analogue' but I suspect this is wrong). Thanks in advance!

[andreasnef]

Ok, good to know. That makes it consistent with other properties.

Regarding the specific properties for analog and digital, I personally don't see much benefit in it, and I would prefer using RepresentationType or similar to distinguish different, well, types of Instantiations. You could group such types into categories analog/digital and imply such a distinction without necessarily require specific properties. But I understand that there are different opinions here.

[williamsonrichard]

BTW, can somebody there confirm that the term 'analog' is the good one in English (above I have used 'analogue' but I suspect this is wrong).

I think this is a question of US vs British spelling, in British spelling 'analogue' would be correct in this context. I guess that there is already a convention for RiC-O as to whether US or British spelling is followed :-).

[florenceclavaud]

BTW, can somebody there confirm that the term 'analog' is the good one in English (above I have used 'analogue' but I suspect this is wrong).

I think this is a question of US vs British spelling, in British spelling 'analogue' would be correct in this context. I guess that there is already a convention for RiC-O as to whether US or British spelling is followed :-).

Hi, I have checked this; RiC is written in British English, so the new property will be hasOrHadAnalogueInstantiation.

[florenceclavaud]

Hi @andreasnef,

Regarding the specific properties for analog and digital, I personally don't see much benefit in it, and I would prefer using RepresentationType or similar to distinguish different, well, types of Instantiations. You could group such types into categories analog/digital and imply such a distinction without necessarily require specific properties. But I understand that there are different opinions here.

I understand this of course, as we also are doing this for now at the AnF. This does not prevent from having a specific object property to say that some Record resource has digital instantiation some Instantiation (and from moving forward and making RiC more accurate as concerns the description of born digital, analogue or digital instantiations). Both features can also be combined (use the property and the representation type). And again this will provide institutions or teams which have to manage legacy metadata encoded in EAD, with a simple path from the EAD dao element to RiC-O triples. As a matter of fact, there often is for now in RiC-O several methods for representing some assertions. IMHO it is well adapted both to a transitional time, and to the fact that we should IMHO rather for now open possibilities and wait for some common practice to help us decide what we may keep or remove.

[florenceclavaud]

Hi all, This is done, the PR has been merged (see https://github.com/ICA-EGAD/RiC-O/pull/66) and now everything is in the version_1-0 branch.

I am closing the issue as completed.