As touched upon in §6a.3.2, the Activity entity is important in RiC. It is very flexible: it might be used when describing functional provenance — there are several examples of this in, for instance, §6b and §6e; or for incorporating context which bears upon a Record Resource in less direct ways, as for instance in some of the examples in §7 and §8; or for expressing meta-metadata, as discussed in §6a.3.4.
Here, though, we will focus upon using Activity to describe archival and records management processes. First we will discuss digitization, and then appraisal and disposition. When it comes to the use of the Activity entity, the same modelling pattern will be used in both cases; it generalizes to many other kinds of processes. Other aspects of the modelling may be of independent interest.
Much of the discussion, especially the core aspect of how the Activity entity is used, is appropriate for a beginner in RiC who has acquired a little experience. Certain aspects are a little more advanced.
As we did in §6b.3, let us consider a parish register for Bratsberg Church between 1938 and 1952. For an example of how it looks, see for instance the page for deaths in 1939 and 1940.
This parish register was scanned in 2005 by the Regional State Archives in Trondheim, a sub-entity within the National Archives of Norway. We might model this as follows, incorporating some context. At its heart is the way in which the Activity entity and the relations affects or affected, results or resulted in, occurred at date, and is or was performed by are used.
Some notes on the modelling:
As discussed §6b.3, we might model the parish register as a Record or a Record Set depending on the context; we have chosen Record here.
The Rule brought into the modelling concerning blocking of pages has been applied to all pages to do with births in the digitization, as can be seen in the early parts of the parish register.
For why digitization is regarded as an Activity pertaining to an Instantiation as oppposed to a Record Resource, see the discussion in §6c.2: the intellectual aspect of the Record Resource — the information it holds — is essentially unaltered; digitization takes one inscription of that information to another. From a more functional point of view, a digitization may make a Record Resource more widely available — online, or via another electronic channel — or it may contribute to more robust preservation of it; but, in the first instance at least, this again has to do with how concrete inscriptions of the information held in a Record Resource are used, without affecting that information itself.
We refer to §6a.3.3 for more on why Activity and not Event is used in all three cases in the modelling, including the one-off Activity of the digitization of this particular parish register: the degree of time that an Activity lasts is not so important in this regard, rather…
An Activity is an agent designed and performed event that has an intended purpose or purposes.
…which applies here.
In RiC-O, one has rico:hasOrHadAnalogueInstantiation and rico:hasOrHadDigitalInstantiation available as refinements of rico:hasOrHadInstantiation; these would complement nicely the use of the Representation Type attribute in the modelling.
Digitization could of course also apply e.g. to audio material; the noting of the Carrier Type and Representation Type of an Instantation as in the modelling, in addition to the inclusion of scanning as a specific form of digitization, allows for deducing which kind of digitization is meant in this case — even by a machine.
The ‘Digitization’ and ‘Scanning’ Activities serve a slightly different purpose to the ‘Scanning’ Activity Type in the model. As is discussed in more depth in §6f, a primary purpose of Activity Type and similar attributes in RiC is categorization — this facilitating simple querying, for instance — often making use of a standardized vocabulary. To this end, as in the other cases, Activity Type is defined in RiC-CM to be non-repeatable, with the expectation that the narrowest available categorization is used, as in the diagram.
The inclusion of the ‘Digitization’ and the ‘Scanning’ Activities, on the other hand, permits us to express the nuance that the one is a special case of the other, but more significantly allows us to connect the digitization of the parish register to a much broader context: all kinds of relations and attributes might have their source in either the Digitization or the Scanning Activity.
If the digitized instantiation in this example were, say, in such a format as to allow for annotating, and if it were indeed to be annotated, it might in the end, as per the discussion in §6c.3, be judged an Instantiation of a new Record. We might model this as follows.
On a different note, as it happens, all of the parish registers for Bratsberg Church up to 1961 have been digitized. We could model this as follows, regarding all of these parish registers as aggregating into a Record Set. The only change from the case of a single register is that the Date Entity is now a period of time (one could make use of the Date Type attribute to emphasize this if one wished).
The modelling of the single parish register with which we began fits into the above as follows.
We turn to an example from the RiC mailing list, discussing appraisal by a records management organization in Flanders of a series which we denote by R. One outcome of the appraisal is the decision to destroy, ten years later (say), a file within the series, which we denote by F. R has an entry in a government register, and the outcomes of the appraisal of R, including the disposition of F, are required by law to be logged in this register.
The register log indicating that F is to be destroyed can be regarded as providing a mandate for that destruction. It so happens in this case that the same records management organization that conducted the appraisal is also likely to carry out the disposition when the time comes. A description in RiC of all of this might look as follows.
Some notes on the modelling:
