W3C home > Mailing lists > Public > public-architypes@w3.org > August 2015

RE: How to describe things in an archive collection?

From: Barbara Reed <B.Reed@records.com.au>
Date: Mon, 10 Aug 2015 02:23:37 +0000
To: Richard Wallis <richard.wallis@dataliberate.com>, public-architypes <public-architypes@w3.org>
CC: "C.Findlay" <C.Findlay@records.com.au>
Message-ID: <CF295C459CB1AF4C9B1662E841269CB50158886F@RKISYDMSG.rki.local>
Dear Richard and all

I’m joining this conversation late and with incomplete knowledge about its origin except that something came up at LODLAM. I want to make a plea to be embracive of diversity, and not define yet more schemas that exclude potential developments. I’m a fan of the CIDOC-CRM model on that front.

In the realm of archival description as outlined by Giovanni, has been well developed for many years. These have always existed partially at odds with Australian archival practice. However, there is a parallel set of developments which can be melded with desirable results. This is the work of the recordkeeping metadata community.  The argument for enabling the melding of a number of worlds within an embracive notion of archive is that it allows multiple methods of implementation and diverse traditions to flourish yet talk to each other.

The use of collection has a physical feel to it that implies location – perhaps not intentionally. Why  can’t archive just stand alone?  It is but one possible aggregation of records. As we know ‘archive’ can be more than a collection – it can be a construct pointing to things designated for that archives in many diverse physical locations. Archive can also occur at different layers of aggregation which need to be encompassed – your archive may be only one of many archive/s that make up my view of archive etc. So I would suggest that the archive schema needs to embrace cascading layers of aggregation, with the capacity to extend at both ends – at the top (always possible to aggregate an archive into another archive), and at the bottom (the attachments to the email, the page of the digitised item).

In broad terms, the recordkeeping metadata concepts allow the cascading notion. There are ‘fixed’ aggregation points being item, transaction sequence series, archive (defined as ‘the whole body of records of an organisation or individual), archives – but you can cascade within those too. The degree of ‘fixity’ is to do with exchange – your concept of item corresponds to mine etc.

Within Australian practice we are having many discussions about Archival Item. Traditionally this has been (relatively) non problematic. It is the physical level at which management control is assigned. With the digital world however, we can digitise pages of a physical item, for example, or have an attachment to an email  – these immediately cause hierarchical relationships within an archival item which need to be managed. So the is part of/has part relationship becomes vitally important. In fact, relationships as a whole become vitally important.

In relation to ownership, this needs to be deconstructed into many parts, as ownership can be many things, but fundamentally it’s a relationship between records and agents who have some form of rights/role:

·         Rights to define controls (eg access, destruction – events that happen, and this is being distributed far more widely than has traditionally been the case with participatory recordkeeping paradigms developing)

·         Creator – the core provenance relationship

·         Custody: who has control of the thing in their descriptive system

·         Location – where is it
And I’m sure there are more.

The recordkeeping metadata exists at a high level of definition in ISO 23081-2. It is a relational model, separating out the description of records entities from those of agents and business, linked by relationships. It has a method of flattening these into a single entity description (of which Archive Collection/Archive Item would be instances). You will see that it also encompasses actions which are planned (event plan) and conducted (event history) on the entities – or record entity if you’re thinking in single entity terms.

The metadata elements are grouped into the following:

Identity

The identity metadata group identifies the entity.


Entity type (record, agent, function, mandate, relationship)
Aggregation
Registration ID

Description

The description metadata group contains elements required to determine that this is the
entity that is required for use.

Title
Classification
Abstract
Place
Jurisdiction
External IDs

Use

The use metadata group contains information that facilitates long-term use of the entity

Technical environment
Rights
Access
Audience
Language
Integrity
Documentary form

Event Plan

The event plan metadata group contains information used to manage the entity. The
metadata in this group consist of a linked sequence of metadata and independent metadata elements

Event Plan:
Event Plan Date/Time
Event Type
Description
Relation

Event history

The event history metadata group documents past records events and other management
events on both the entity and its metadata. For each event it specifies the type of event, what happened, when it took place, why it occurred, and who carried it out. The metadata in this element are a sequence documenting a specific event.

Event:
Event ID
Event Date/Time
Event Type
Event Description
Event Relation

Relationship

The relation metadata group points to a relationship entity or describes the relationships
between this entity and other entities.

Either: Relationship ID (where relationships are managed as a separate entity)
Or
Identifier for related entity
Relationship type (eg contained/part, sequential etc)
Relationship date


It would be fabulous to define schemes that bring things together and enable connections, not create more non-connected schema.

Happy to contribute if I can find the connections to what I do….

Kind regards

barbara

Barbara Reed
Director, Recordkeeping Innovation Pty Ltd
+61 2 9369 2343



From: Richard Wallis [mailto:richard.wallis@dataliberate.com]
Sent: Wednesday, 5 August 2015 8:04 PM
To: public-architypes
Subject: How to describe things in an archive collection?

In other threads we have been discussing how to describe an Archive as an Organization/LocalBusiness<http://lists.w3.org/Archives/Public/public-architypes/2015Jul/0002.html> when appropriate, and how to describe an ArchiveCollection<http://lists.w3.org/Archives/Public/public-architypes/2015Jul/0008.html>.  Now I think it is time to add one more area to our attention - how to describe the physical/digital things that we find within an archive collection.

In archives we find all types of things from creative works such as books, letters, artworks, videos, web pages etc., to furniture, personal items, vehicles, fossils, rocks and of course the favourite box of things yet to be identified.  From what I understand there are certain common categories of things such as physical creative works, digital creative works, physical containers of things identified or not, but it would be far too limiting to build our recommendations around these.  The result is that we need to be able to describe anything that could be found in an archive which means anything!.

Fortunately in our world all these things have one aspect in common - they are in an archive.

If we can establish a set of descriptive properties that would be of use in describing an item's place and role in an archive, we can then look to some, schema.org<http://schema.org>, techniques to apply them alongside other properties that are already available in the Schema vocabulary.

Properties that come to mind include:
isPartOf - a reference to the collection a thing is in
condition - state of preservation of an item
containedIn - the box or digital file containing the item
curatedBy
curationDate
CurationEvent - possibly a better way to describe a curation event - linking where when and by who
location - of item, not necessarily the collection location

We could look to already existent standards, CIDOC-CRM for example, as a source of inspiration.

So, over to you for suggestions.  Once we have assemble a few by email discussion, we can create a page in the Wiki to capture them and become the basis for the core of our proposals.

~Richard.


Richard Wallis
Founder, Data Liberate
http://dataliberate.com

Linkedin: http://www.linkedin.com/in/richardwallis

Twitter: @rjw

--
ExchangeDefender Message Security: Click below to verify authenticity
https://admin.exchangedefender.com/verify.php?id=t7A2OJor012421&from=b.reed@records.com.au
Received on Monday, 10 August 2015 06:50:12 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 August 2018 13:28:59 UTC