Skip to end of metadata
Go to start of metadata

Following on from work with Carl H here, I've chosen a tiny area of the problem space "Accession Numbers" and written what I'd typically give someone who's architecting the data-model/UI etc. I think this roughly corresponds to where we might put the functional-techical interface, and so the kind of document which (I as a member of) the techincal team might like to see at the technical end of the "functional gap".

IMPORTANTLY this is not real analysis informed by serious museum input: but is here because it has a form which I think would be useful, addressing issues in an informatics way, and so on. We'd need a document created by experts similar to this to handle accession numbers in practice.

It's an attempt to illustrate a genre, not tell any particular story. -- dan

The endnotes would me assumed knowledge for a technical document, but are added here to contribute to sense.

"Object Reference Number": technical sheet

Data Context

An object reference number is recorded as a value within an object record and is typically

  • unique (but not always)
  • prominent
  • present (but not always)

An object reference number identifies an object, (not a record) and associates it with its record in the CMS. A property of the object (for example marking) will be sufficient to derive the object's reference number, which can then be used to identify CMS record(s) for the object. Therefore search for a CMS record "using" an object is surrogated by search for record by means of the object's reference number. This is analogous to searching for a shipping record "using" a parcel, by entering the shipping number of that parcel. An object reference number thereforealso exists outside the CMS.

Object reference numbers are drawn from a number of identifier generators

  • accession numbers, for accessioned objects
  • loans in numbers, for loans
  • temporary instances of such, where there is a delay between arrival and assignment

The subtype of object reference number will typically be distinguishable from other generators.

Other than context derivable from impure1parts of the object reference number, an object reference number establishes unidirectional binding from the object to the record, the other direction being provided by location information. The object reference number tends to be the authoritativepartner in this association4,.

Object is used here in a technical (museum) sense: the object tends to bea strong concept in museums: though composite and decomposable "things" exist, what is the object and what merely a part thereof, or a collection thereof, will be strongly determined by the museum, and it is at this unique and well-defined objectlevel that object reference numbers bind.

Additional lot/collection and part numbers will exist to handle composite/decomposed things. _However,_in some cases impure1properties of an object reference number are used to create implicit relationships (eg Z-123a, Z-123b, etc, being pages in an album), from which a group identifier is then derived (eg, Z-123). Occasionally, in some museums, this may be regarded as an object reference number number (and an object) in its own right, with its own object record(s).

"Accession number" is often used in informal contexts to refer to all kinds of object reference number.

Data Type

An accession number, or other object reference number, is an identifier. It is a short string, often divided into sections by punctuation, or fixed field widths. They may or may not be case sensitive, but usually will not be. If they are not case-sensitive there will be an established canonical case for a section. Sections may carry meaning by their absence2, though many will be mandatory. Undelimited sections will, nevertheless, be algorithmically, and unambiguously decomposable into sections.

Each section of the identifier may carry meaning (be an impure name1) or not (a pure name1). Even apparently pure numeric sections are typically assigned sequentially, and therefore have meaning by comparison. As an accession number containing impure name parts is impure, and since the presence of an accession number outside the CMS implies inherent impurity, an accession number should be considered impure.

Sections of an accession numbers will have per-museum defined collation orders, which are typically alphabetic and lexographic3 for textual sections, and numeric for numeric sections, the sections themselves then being collated lexicographically.

A great deal of effort and imperative surrounds the need for stability, immutability, and uniqueness of accession numbers. However, when mistakes occur (typically through identifier impurity) they must be correctable.

Some smaller institutions (particularly galleries) have narrative accession "numbers" which are difficult to compare automatically, because they exist in different equivalent forms.

Data Model

As an impure name, an accession number (or other object reference number) makes a poor primary key, but contain a strong requirement for efficient search for human discovery. It may make sense in some contexts for a pure surrogate for the object reference number to be used within the CMS, to allow continuous history across accession number corrections, transitions between object identifier states (eg a loan which is later accessioned), or modifications of impure sections of the accession number. Let's call such an identifier the pure object identifier (poi). This identifier (if used) must be internal only, to retain the primacy of the object reference number within the museum: this is a situation analogous to the manner in which svn carries over history through file name changes5. The poi must be pure1.

There is certainly a need for a pure record identifier (pri), separate from the object reference number and poi (if any), as a surrogate for the exclusive physical extent and pointability of the index card. At any time, an object may, in many museums, have more than one record (perhaps in different containers or states); a record may be created for which there is, perhaps only instantaneously, no accession number; and so on. The pri should be stable6 and therefore pure.

In simple initial installs, the pri/poi/accession-number should be isomorphic, and UI details hidden, particularly the poi/acc-num association (if poi's are used), which should perhaps only be surfaced when it is necessary to ask questions, eg "you seem to have updated this record of X, would you like me to update other records of this object (Y,Z) to reflect this change.", and in aggregate distribution, such as aggregate multi-museum collections, and so on. Such multi-museum aggregation would suggest a globally-scoped identifier space for poi/pri (such as GUID), with poi's necessarily requiring an equivalence-set/canonical-representative service, which will be reliant on an authority, not objective (different opinions as to equivalence).

Type of thing

External Type Structure

Purity/Internal Structure

Externallity

Association

Authority and Presence

Object Identifier (eg accession number)

Often subtyped according to status within museum, eg acc num, loans in, etc.

Structured, impure, complex collation, museum-scope

Externally visible and prominent

Attaches to an object during its lifetime within a museum, at least as long as it has some particular status within the museum (accessioned, loaned, etc)

Museum. Necessary.

POI

None

Pure, open-scope7

Internal

Associated with an object indefinitely, through multiple object identifiers, etc. Through "equivalence services" can be used to track across museums if desirable.

CMS. Optional.

PRI

None

Pure, open-scope7

Largely internal

One CMS object record

CMS. Necessary.

EndNotes

  1. In the standard Needham/Distributed System sense of pure/impure: pure names yielding no information themselves, (eg random sequences of digits), and therefore immutable, uncontroversial, incontingent identifiers. For example an SSN/National Insurance ID is pure, as it is a random number. If it were to incorporate, eg, personal initials, it would be impure, and so come with an overhead of managing changes, corrections, questions of authority, etc.
  2. For example, S-56, ..., S-99, S-99a, S-123, S-124, S-124a, S-125, S-125a, S-125b, etc, contain three sections. A single letter section, collated lexicographically; a "-" separator; a second, variable length numeric section, collated numerically; and a third single letter section, collated lexicographically, which may be absent. The three sections then collated lexicographically.
  3. Lexicographic sorting has a specialist meaning here: first an order is established amongst members to be collated (typically the established linear order), and then the first part is collated according to the collation rules for that part. Only if there is a tie in this first part is the second part inspected, and so on. Therefore lexicographic sorting includes standard "library" sorting (alphabetic+lexicographic), right-padded digits, ISO-format dates, sections of an accession number, and so on.
  4. In practice, bidirectional links can conflict, such that going one way then the other does not end you up where you started. It's usual to identify an authoritative direction, even in non-IT situations. Here, we have accession numbers pointing from object to record, and location information pointing from record to object. If location information tells you that an object is at such-and-such a location, but when an object is retrieved from that information it has a different accession number, the typically it is not the object, rather than _the accession number on the object needs to be changed_.
  5. SVN is a system for tracking the history of files. Externally they are represented by their filename uniquely. However, "going back in time" that the file once had other properties, and the history of that object is retained.
  6. ie not change so that it can be referred to.
  7. Open-scope, ie globally unique, enabled through purity of identifier1.
  • No labels