Request to rename RiC-A36 from "Record Set Type" to "Record Resource Type"

[wildit]

We propose to rename RiC-A36 from "Record Set Type" to "Record Resource Type" and the relations rico:isRecordSetTypeOf / rico:hasRecordSetType to rico:isRecordResourceTypeOf and rico:hasRecordResourceType. With Range "Record Resource" instead of "Record Set".

Our argument is that also Records can be of multiple levels and nested -- and we need to categorize the different layers of them. Eg. a dossier/file contains different items. Btw. we consider the whole dossier/file as a record and not as a record set. It's a tangible physical unity and you can attribute a documentary form type to it.

[dpitti]

Tobias,

I note one thing below that makes explicit something that has only been implied in the manner in which “file” has a “betwixt and between” quality, that is, it is spoken of as an item that is defined as being a set of items.

"It's a tangible physical unit…”

Suggests that the records in a file must be physically proximate if not in fact bound as a physical thing for a file to be a file Thus if the records in a file are not physically proximate (or possibly bound), the file does not exist. Is this true?

Btw. we consider the whole dossier/file as a record and not as a record set.

If I recall, did we not make it possible for a Record to contain/include a Record?

Please hold off on making any changes to Record Set Type, as I think we need to first resolve the Record Set versus Record, and following Record Resource. My sense here is that we are beginning to drift towards the ISAD non-distinction between Record and Record Set.

Thanks, Daniel

On Jun 25, 2020, at 9:29 AM, Tobias Wildi notifications@github.com wrote:

We propose to rename RiC-A36 from "Record Set Type" to "Record Resource Type" and the relations rico:isRecordSetTypeOf / rico:hasRecordSetType to rico:isRecordResourceTypeOf and rico:hasRecordResourceType. With Range "Record Resource" instead of "Record Set".

Our argument is that also Records can be of multiple levels and nested -- and we need to categorize the different layers of them. Eg. a dossier/file contains different items. Btw. we consider the whole dossier/file as a record and not as a record set. It's a tangible physical unity and you can attribute a documentary form type to it.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[wildit]

Daniel,

I'd like to refer to this example to illustrate my concern: https://icae.esrc.info/objects/Example%20Volksgericht%20Graphic%20with%20relations.pdf

The description drills down to the Record level with a type "File". Now this File contains probably several documents and if we'd catalogue them one by one, each of them would have a type "Item".

I absolutely don't want to go back to the non-distinction between Record and Record set. My only argument is that also a Record may have an inner structure, if it's a File that contains Documents, a Website that consists of many html-pages or an Email that contains Attachments. These are not only "Record Parts" and we'd like to categorize them.

I'm well aware that this question has to be discussed on the level of the CM and not the O!

Best, Tobias.

[wildit]

If I recall, did we not make it possible for a Record to contain/include a Record?

That would solve the main problems. RiC-R024 would need a Domain/Range-change from "RecordSet" to "RecordSet" and "Record".

[dpitti]

Tobias,

I do think Record needs to be able to contain Record, of the reasons you give.

I suspect that not everyone will consider a file a Record. Thus when one does, then it can have a Documentary Form Type. Would this be “File?” And then for those that treat a file as a Record Set, it would have the Record Set Type “File.” My experience is that people being trained always want the world to be “black and white.” But as such alternatives go, this is by no means not the most vexing I have seen. I think at broader level, in the scope note for Record Resource, we make clear that it is not always easy to decide when a “thing” is a Record Set or a Record.

Again, I need to go back to wrestling with the attributes, and I will keep this in mind as I do so.

Regards, Daniel

On Jun 25, 2020, at 10:19 AM, Tobias Wildi notifications@github.com wrote:

Daniel,

I'd like to refer to this example to illustrate my concern: https://icae.esrc.info/objects/Example%20Volksgericht%20Graphic%20with%20relations.pdf

The description drills down to the Record level with a type "File". Now this File contains probably several documents and if we'd catalogue them one by one, each of them would have a type "Item".

I absolutely don't want to go back to the non-distinction between Record and Record set. My only argument is that also a Record may have an inner structure, if it's a File that contains Documents, a Website that consists of many html-pages or an Email that contains Attachments. These are not only "Record Parts" and we'd like to categorize them.

I'm well aware that this question has to be discussed on the level of the CM and not the O!

Best, Tobias.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[florenceclavaud]

This issue is related to issue #5 that I opened a few weeks ago.

While I think having a RecordResourceType class instead of DocumentaryFormType (or, maybe better, as a superclass of DocumentaryFormType) would be good, I did not have exactly the same arguments in mind as you, Tobias. I just think that, while some archivists will consider some record resources as Record, other ones may consider them Record Set. And that, if we have a RecordResourceType, it may help, for now, to handle such situations - till the archival community has built a common, multilingual, vocabulary for record resource types, where each concept would be defined unambiguously as being either a Record Set Type, or a Documentary Form Type (we should dream).

ABout the "file" case: if we stick to the ISAD(G) definition of File ("An organized unit of documents grouped together either for current use by the creator or in the process of archival arrangement, because they relate to the same subject, activity, or transaction. A file is usually the basic unit within a record series"), a file is a Record Set. I would say a website is an aggregation of documents, and thus a Record Set. And, like Daniel, I think most archivists would say the same. BTW, RiC-O comes with some individuals, instances of DocumentaryFormType or of RecordSetType. Among these, you will find File, a an instance of RecordSetType :

file An organized unit of documents grouped together either for current use by the creator or in the process of archival arrangement, because they relate to the same subject, activity, or transaction. A file is usually the basic unit within a record series. (From ICA ISAD(G)) file

[florenceclavaud]

Hi all, I think we will not solve this issue for RiC-O 1.0. In fact, I would rather keep RiC-O as it is now as concerns this topic, and not introduce RecordResourceType. I think it would make things confusing, as we have subclasses of RecordResource.

@wildit, if you consider a file (as you described it above) is a Record, then you can assign a rico:DocumentaryFormType to it. DocumentaryFormType also has domain RecordPart BTW.

What we should do, however, is extend the domain of hasOrHadConstituent to Record Part, and its range to Record. Anyway this would be consistent with the current definition of Record in CM 1.0, that says "[...] A record may itself contain one or more records,[...]." Also, of course, a RecordPart may be constituted of several RecordParts - just as CM also says.

[florenceclavaud]

I am closing this issue as solved by #78 (hasOrHadConstituent, its subproperties, its inverse property and the subproperties of the inverse have been updated, and now have domain Record or RecordPart, range the same.