ev0hhp7t

1#Comments on Records in Contexts: A Conceptual Model for Archival Description
2##Consultation Draft v0.1 September 2016
3
4<b>Date</b>: 30 January 2017.<br/>
5<b>By</b>:   Ross Spencer < all.along.the.watchtower2001 [at] gmail.com >
6
7###Background:
8
9I'm a digital preservation expert working at Archives New Zealand. This 
10short response to the consultation draft is submitted independently of my
11organisation.
12
13I have worked previously at The National Archives, UK. I have a keen 
14interest in supporting archivists and end-users to make full use of the 
15collections that we are custodians of. 
16
17###General Comments:
18
19I believe I join in the good majority of the community in expressing my 
20gratitude about being given the opportunity to comment on the consultation
21draft.
22
23I am in favour of the approach taken by ICA to combine multiple standards 
24into a single new standard (p1). I think the work done on this draft is
25phenomenal, and despite very specific comments below about features of the 
26modelling work thus far, this is a standard that I think paves the way to
27a bright future for archival description and discovery. 
28
29Whatever way the standard evolves, it is one I hope to be using in the near
30future. 
31
32###Specific Comments: 
33   
3401.   I am in favour of an approach that embraces the techniques of linked 
35      open data (LoD) (p2).
36   
3702.   A clearer delineation/description of the differences between RiC-CM 
38      and RiC-O would be beneficial and may help resolve other concerns 
39      noted below, e.g. expansion of controlled-vocabulary terms (p1). 
40   
4103.   Comments establishing the standard within the LoD/semantic web 
42      ecosystem would be appreciated. The comments should survey the 
43      semantic web landscape and discuss complimentary standards that are 
44      recommended by ICA to be used alongside any future RiC model. 
45
4604.   The standard is very wide ranging. In its early stages I would 
47      consider it to be too broad. I ask the ICA to consider a more 
48      restricted version of this standard that is more concise. Comparable 
49      to other LoD standards such as Dublin Core (15 elements), SKOS (32) 
50      vs. RiC-CM ~800 (?).
51   
5205.   A restricted set could focus on features of the vocabulary that are
53      absolutely necessary, and can be used by the widest possible audience 
54      to support management and discovery of archives. 
55   
5606.   A restricted set could be monitored for use and iterations built upon 
57      henceforth.
58
5907.   It is noted that the 'relations' described in the paper are 
60      suggestive. When 'rounded out' it should also be noted that using LoD 
61      techniques 'relations' become 'resources' in their own right (the 
62      predicates in the subject, predicate, object, triumvirate). That makes
63      them something the user will look up more information about. As such 
64      the data they contain should be as complete as the entites themselves.
65      
6608.   Because of this then, additional consideration should be given to 
67      point 05. I raise above, where I call for an initial, more concise 
68      vocabulary to be considered. There is a maintenance overhead of a 
69      large vocabulary that (the lack of description in v0.1) may be an 
70      indication of an existing reality. 
71      
7209.   A vocabulary that is too broad could have a dilutant quality impacting
73      discovery, whereby, a wide variance of terms are used to describe too 
74      large a number of records creating smaller results sets when using 
75      techniques such as faceted search. (Posit, a smaller number of
76      properties across a larger number of records creates larger results 
77      sets)
78
7910.   I appreciate the inclusion of an authenticity and integrity note 
80      (RiC-P5). I would like to see this expanded further for digital with 
81      a separate field, or set of fields that have a specific data-type of 
82      'checksum' i.e. a field that can be validated as being just a checksum
83      only.
84    
8511.   A checksum is a mechanism by which a digital file in 'a' digital 
86      repository can be reliably paired with a catalogue entry. By having an
87      explicit mechanism for attaching checksum or sets of checksum to the 
88      catalogue it promotes computerization of processes between the two.
89      
9012.   On that note, I would like to see the LoD concepts committed to more
91      fully. Where there are facts to be recorded - a checksum being a fact
92      about a digital record's current state - more rigid properties can be
93      created and used. 
94      
9513.   RiC-P39 (Contact Information) is an example of a property that can be 
96      expanded into 'facts'. Email address, postal address, phone number. 
97      All properties that can be validated in some way, and that might be 
98      desirable to be searched upon in some way. Conditions of use, where 
99      licenses could be searched upon, may be another useful example. 
100      
10114.   RiC-P6 (Content Type) will be set via controlled list. Controlled 
102      vocabularies such as in this example, where not otherwise specified 
103      (e.g. as in MIME) should be described fully by this standard as
104      resources that can also be looked-up and de-referenced to provide more
105      information.
106
10715.   To promote interoperability, data types should be specified more fully
108      e.g. preferred/expected number, text, or date formats, plus strategies
109      to resolve areas of ambiguity, such as for dates, where precision may 
110      not always be possible. 
111
11216.   RiC-P10 (Encoding Format) is a good example of a field explicitly made
113      available for digital. Properties such as RDFS:Domain may become 
114      important as an ontology develops out of this work. What is the ICA's 
115      chosen approach to managing the lines between paper and digital where
116      properties may or may not make sense to one record type over the 
117      other? 
118      
119###Conclusion:
120
121The consultation draft makes adequate attempts to caveat its work in places,
122including:
123
124"It is essential that developers	of records management and record 
125description and access systems are part of RiC’s audience. RiC is detailed 
126and complex, and therefore successful implementation and use will require 
127the development of methods that will ameliorate the intellectual, 
128technological, and economic challenge of data creation and maintenance."
129
130It is possible therefore that some of my suggestions above have been
131considered to be out of scope currently; or simply not relevant to the 
132future goals of this standard.
133
134It is also likely that for realistic questions raised, they will be 
135answered during the proving stages of Records in Contexts where I hope to be
136an active participant in working with the new standard. 
137
138Thank you once again for the opportunity to contribute thus far.