Very interesting discussion. I am in mid-travel right now but just wanted to
add a couple of quick comments.
Firstly, the ICA-AtoM data model is designed in such a way to support all of
the Series system scenarios which Maggie has highlighted. In fact, the
decision to create an Event object (in the underlying ICA-AtoM data model)
seperate from the Archival Description and Authority File objects is based
very much on the 'Business' entity in the Australian SPIRT Recordkeeping
The next step is, as Evelyn has suggested, to create an 'Australian' or
better yet a 'Series system' specific template that addresses the specific
display issues. Given our cramped development timeline that may still be a
couple of months away but we'll certainly use this discussion and any future
feedback as design requirements when we begin that task.
> The main way the software isn't coping with the series system is in
> the display of creation dates and creators. Series ANUA 2, 14, and 25
> are examples where I've entered successive creators and the dates they
> created the series (not always the same as the creator's dates of
> existence) but the dates just stack up in reverse order separate from
> the creators.
Given that we allow for multi-creator scenarios in general, perhaps we
should change our default display to put creators next to their
corresponding creation dates in the display templates. Evelyn, can you pls
file a (1.0.5) issue for this and discuss it further with Richard.
> The relationships area which isn't there yet is also crucial to the
> series system: the elements needed are temporal (previous/subsequent)
> and hierarchical (controlling/controlled), plus 'other' because
> there's sometimes something odd not fitting into these.
Yes, ISAAR Relationships is a priority for the 1.0.5 release (likely due by
> Another thing which is crucial to us under privacy legislation is
> whether the records are owned (either created by the Commonwealth or
> donated to it) or deposited (still owned by the creator or its
> successors) as there is one regime under the Privacy Act for
> Commonwealth records and another for non-Commonwealth records. I
> haven't entered this information yet as all ANUA series are owned, but
> I thought I'd just use 'Immediate source of acquisition' and rename
Try to determine if this field legitimately maps to the ISAD field.
Presumbly there is an Australian Standard to ISAD(G) crosswalk we can
reference. If there isn't a clean mapping then let's not substitute fields.
We have a mechanism to add new fields (QubitProperties) which we would
implement when we create an Australian Series template.
> I'll get back to you with other comments as I encounter new scenarios
> - the main problem is that entering our data exposes our inconsistent
> practice over the years - not just that one part of the collection is
> series system and the bulk is record group - but all sorts of oddities
> that were introduced as a solution to a particular problem without
> foreseeing their implications. One field I really, really need at the
> item level (your 'file' level) is 'Alternative number' with multiple
> occurrences because we often record a file number allocated by the
> creator which has been superseded by an imposed single number. This
> would also assist us at the folio level (your 'item' level) with maps
> and photos which have been allocated map numbers, photograph numbers
> and negative numbers in addition to their deposit and item numbers. An
> alternative number field at the deposit (fonds) or series level means
> you can enter a previous number (eg when records move from one
> repository to another or for some reason you convert them to another
> number) and you can confirm that these are the same records.
I think this is a universal problem/requirement for archival systems around
the world. Evelyn, can you please add this requirement (multi-value,
alternate number field) to the 1.0.5 new features list. We'll handle this
either with a QubitProperty or QubitNote.
Peter Van Garderen,
Software Release Manager,