{"id":1246,"date":"2017-02-02T09:45:32","date_gmt":"2017-02-01T22:45:32","guid":{"rendered":"http:\/\/www.mikejonesonline.com\/contextjunky\/?p=1246"},"modified":"2019-07-22T16:40:55","modified_gmt":"2019-07-22T06:40:55","slug":"comments-on-records-in-contexts","status":"publish","type":"post","link":"https:\/\/www.mikejonesonline.com\/contextjunky\/2017\/02\/02\/comments-on-records-in-contexts\/","title":{"rendered":"Comments on Records in Contexts"},"content":{"rendered":"

In September last year the International Council on Archives’ Expert Group on Archival Description (EGAD) published the first consultation draft of\u00a0Records in Contexts: A Conceptual Model for Archival Description<\/a>\u00a0with the call for comments closing on 31 January 2016. I submitted some hastily-assembled thoughts on the final day. For those interested in such things, here they are.<\/em><\/p>\n

Comments on\u00a0Records in Contexts: A Conceptual Model for Archival Description –\u00a0<\/strong>Consultation Draft v0.1 –\u00a0<\/strong>September 2016<\/strong><\/p>\n

I would like to thank the International Council on Archives and the Experts Group on Archival Description (EGAD) for the opportunity to comment on this draft, and congratulate EGAD for the work and depth of thinking that has clearly gone into preparing the document.<\/p>\n

General comments<\/strong><\/p>\n

I fully support the intent of the work as outlined in the introductory sections, particularly the move to bring key aspects of the four existing ICA standards into a single combined conceptual model. I also recognise the necessity of more fully supporting the ability of the archival community to make description available as Linked Open Data (LOD).<\/p>\n

The consultation draft is strong throughout and provides an excellent starting point for discussion with the broader community.<\/p>\n

However, while the entire draft conceptual model is clearly based on a lengthy series of discussions, internal (to EGAD) drafting processes, and no doubt some disagreements and debates, the justification for particular decisions is not always clear.<\/p>\n

For example, the introductory sections make a clear case for the need to look beyond hierarchical, inward-looking description to effectively capture contextual complexity; but prior to this the \u2018primary description entities\u2019 are presented without explanation or discussion. The document states that \u201cthere has been extensive analysis of each of the existing standards\u201d leading to this decision, but the justification for the resulting list is not provided.<\/p>\n

Similarly with the distinction between \u2018entities\u2019 and \u2018properties\u2019, and the definition of these (and other key terms) used within the document. What is an entity here? Why was the decision made to make date an entity rather than a property within this model? Though what there is in the introduction is mostly strong, there is implicit knowledge which needs to be made explicit to bring the rest of the community (people not involved in the EGAD process) on the journey.<\/p>\n

Specific comments<\/strong><\/p>\n

p9-10: Without seeing further justification, I am not convinced by some of the \u2018primary entities\u2019 as given, in particular \u2018Agent\u2019, \u2018Function (Abstract)\u2019, and \u2018Date\u2019.<\/p>\n

Agent<\/strong>: The term \u2018agent\u2019 raises a lot of issues. I see agency as relational, emerging from the interaction between a thing and other things to which it relates \u2013 its context. It is neither an entity type nor a property; and my preference would be to use e.g. \u2018Person\u2019 and \u2018Group\u2019 as entities.<\/p>\n

Leaving to one side the complexities of contemporary theories of agency, in this document Agent (RiC-E4) is defined as: \u201cA person or group, or an entity created by a person or group, that is responsible for actions taken and their effects\u201d (p.14). Then there is an entity \u2018Concept\/Thing\u2019 (RiC-E14) which includes in its scope \u201call RiC entities\u201d (p.19).<\/p>\n

The fact the properties for this second entity have no scope or examples listed (p.38) may be creating confusion; but it seems to suggest a person could be a concept\/thing in some contexts and an agent in others. Or, if all people are agents, the definition seems to strongly preference recording creators and collectors over others (contrary to the more complex ideas about provenance supported in the introduction).<\/p>\n

To understand a collection of records created by an orphanage about a child we might want to capture that child as a person in our network \u2013 are we going to suggest they were \u201cresponsible for actions taken and their effects\u201d in relation to the records about them? Or are they a \u2018Concept\/Thing\u2019 and only become an \u2018Agent\u2019 when they collect their own records? That person may have differing degrees and types of agency at different times and in relation to different things; agency is not a binary, something one has or does not.<\/p>\n

Function (Abstract)<\/strong>: I don\u2019t see the value of including this. The definition states that it is \u201cindependent of the instances of the Function that is specific to a particular social and cultural context.\u201d As both the examples are organisational, does this just mean \u201cdistinct from an individual organisation\u201d? In a broader context? In the context of the domain being described? If the function of the word \u201cparticular\u201d is intended to suggest one or either of these things more clarity is needed; and the purpose of capturing such an entity made clear. Why is capturing contextualised functions not enough?<\/p>\n

Date<\/strong>: A justification is needed for this being an entity and not a property. It seems likely, on reading the document and knowing something of its context, that the idea is to separate out time and place from the specifics of records and other entities, because they are \u2018things\u2019 in their own right.<\/p>\n

In separating out place as an entity (which I agree with in RiC-CM) it seems as though \u2018date\u2019 followed. Time and space are dimensionally interrelated, both endlessly divisible, the ways they are described are culturally specific, and we want to locate our (other) entities in time and space. But, though theoretically interesting, there are significant practical problems in terms of the complexity of the resulting network and the document does not give enough guidance to readers as to how this would work (and why it is necessary).<\/p>\n

I understand this is not an implementation document, but the example network provided in Appendix 1 (p.93) seems to suggest dates would be, for all intents and purposes, used and appear like properties for any actual implementation. If date is to be retained as an entity, I would request that the examples provided in the document need to more clearly illustrate how the multitude of dates required in description will be incorporated into the network the model proposes.<\/p>\n

Also, \u2018Date\u2019 finally appears as a property, but only for relations (RiC-P68 \u2013 p.91), with no explanation as to why there is a sudden change. (Is it simply because relations are not treated as entities? See comments on Relations below.)<\/p>\n

A few more minor points:<\/p>\n

RiC-P5 and RiC-P8 seem to have quite a bit of overlap as described in terms of whether the record is \u201cwhole and complete\u201d and whether the record has \u201clegibility and completeness\u201d, and the examples both mention lost text due to damage (p.22)<\/p>\n

Looking at records, and compounding the complexity of \u2018date as entity\u2019 (above), the property-like dates which could be associated with a record include creation and modification dates, the temporal extent of content, the temporal extent of the carrier, time and date periods related to access, use and history, and more (p.22-26). As presented, with date removed from any discussion of properties, it makes it hard for a user to conceptualise what this might look like. A section integrating entities (particularly date and place) with properties might alleviate this.<\/p>\n

RiC-P18 Conditions of Access: Access could be an entity type in its own right. Ideas like \u2018Restricted\u2019 or \u2018Closed under data protection legislation\u2019 are contextual and bounded by time and place, and often require description, explanation, related records\/evidence, stem from Mandates, etc. Furthermore, elevating access in some form to an entity would shift the balance a little away from what is still in some ways a very \u2018creator-centric\u2019 model and show that user and access conditions are also first-level entities in the archival view of the world (p.25).<\/p>\n

RiC-P26 Arrangement could do with a little more clarity in terms of its scope and examples. The idea of a set of records intellectually but not physically arranged alphabetically is a curious one \u2013 does this mean e.g. \u2018in folders labelled A, B, C, etc.\u2019 even if they haven\u2019t been stored in this order? (p.27)<\/p>\n

RiC-P34 Language information: is the language \u2018used by the Agent\u2019 a property of a relationship rather than a property of the Agent? In the context of archival description a person doesn\u2019t \u2018have a language\u2019, they are using a language to write a document, to conduct business, to take part in a transaction, or similar. The property should be attached to the relationship; otherwise we may know they use four languages but don\u2019t know when they use them and for what.<\/p>\n

RiC-P36 Gender: in support of comments made by others as part of this consultation, the way gender is applied, the vocabulary used, the means for representing people who identify with different genders or have varying gender expressions at different times, and the reasons for capturing gender in the first place (when is it required? why is it required?) need to be carefully considered.<\/p>\n

Relations<\/strong><\/p>\n

Some points on relations:<\/p>\n