<?xml version="1.0" encoding="utf-8"?>
<html>
New History System - old page preserved below
Plan for New History System for DSpace
After examining the state of the current
Code Block |
---|
HistoryManager |
and the data it produces, I'm inclined to discard
it and write a complete replacement.
Since the PLEDGE project needs
a functional history system, we are motivated to rebuild it
in time for the next major release (1.4).
The next few sections describe my strawman proposal for a new DSpace
History System. The original contents of this page are preserved below,
and contain some different perspectives on the design of a history system.
NOTE: This is an initial sketch of a proposal, it is not yet even
complete, but I want to put it in the wiki as early as possible to
gather responses – so please add your comments in the "Comments" section
below.
Goals
- Preserve a fixed, unchangeable record of all significant changes to those data objects in a DSpace repository that are to be preserved.
- Only consider changes to
objects.Code Block Item
- "Changes" include creation, add/remove bitstreams, changes to Item-level metadata, changes to bitstream-level metadata, withdrawl/reinstatement, deletion.
- Associate the person responsible with each change event.
- Record only such details of each event as are really necessary for provenance, e.g. new metadata values, but not bitstream contents.
- Only consider changes to
- Give access to the history data, by Item and through free-form queries.
- Carry the relevant history data with an Item when it is moved from one DSpace repository to another.
- Migrate whatever data can be reclaimed from the old DSpace history system.
Non-Goals
- This is not a versioning system, so it does not usually attempt to record the substance of a change (e.g. contents of bitstreams).
- Do not record any events that do not result in changes to the archive, so the history will not have records of disseminations.
- Do not record changes that are only relevant within the archive, such as authorization policies, EPersons, Community and Collection hierarchies, etc.
- Only record history data for objects that are in the archive, which means history is not recorded for Workspace and Workflow objects.
Justification
If the purpose of saving history data is to establish the provenance of
objects archived in DSpace as an aid to future preservationists, it makes
sense to only save data about the objects which are to be preserved.
This excludes transient object (e.g.
Code Block |
---|
WorkspaceItem |
,
Code Block |
---|
WorkflowItem |
,
and objects that are only meaningful in the context of their home
DSpace archive:
Code Block |
---|
Collection |
,
Code Block |
---|
Community |
, and especially
Code Block |
---|
EPerson |
.
Note that the grouping of Items represented by a Collection can also
be expressed in the Items' metadata, a much more "preservable" manner.
Since preservation probably means transferring (or copying) Items to another
repository or archive at some point in the future, there should be a way
to include the relevant history data with each Item.
UPDATE: Actual History Schema
As of November, 2006, the actual RDF schema emitted by the new history
implementation is simpler and more streamlined than what was first
described here. The following outline of the schema describes what
you should expect to find in the RDF description of each event.
Namespaces=
Panel | ||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||||||
|
URIs to Identify Archival Objects
History records need a "normalized" way to refer to all DSpace Objects,
so there is a 1:1 mapping from identifier to object.
We have to be able to look up the History records relevant to the
object later, as well as generate the URI for an object when entering
new records about it.
Since not all archival DSpace objects have Handles, and in fact the
persistent identifier mechanism is likely to change in the near term, we
cannot use Handles for this identifier. That leaves database ID numbers
(along with the object type to discriminate between IDs). Although this
is not "archival" since the IDs might differ if the object is moved to
another archive, the History records from a single archive should be
self-consistent.
Panel |
---|
XXX needs clarifying.. |
The History record does need to include the mapping from Handle (or
other persistent identifier) to the normalized object URI – this is
provided by the
Code Block |
---|
abc:instanceOf |
property described below.
See ObjectUri for
a description of the current "best practice" in generating URIs.
Panel |
---|
Action resources
Every event creates a unique resource representing that action, which has
a uniquely-generated (but otherwise meaningless) URI.
It can have the following properties:
Code Block rdf:type abc:Action
– value is a URI corresponding to event types in the EventSystemPrototypeCode Block rdf:type history:''action-type''
Code Block history:Add
Code Block history:Remove
Code Block history:Create
Code Block history:Delete
Code Block history:Modify
Code Block history:ModifyMetadata
- One of (
) SubjectURICode Block abc:creates | abc:destroys | abc:hasPatient
ISO 8601 timestamp (from event)Code Block abc:atTime
URI of DSpace ArchiveCode Block history:inArchive
ObjectURI – if there is an ObjectCode Block abc:involves
EPerson-URI (if available)Code Block abc:hasParticipant
ExtraLogInfo (if available)Code Block history:usesTool
(if available)Code Block history:detail "event.getDetail()"
(if available)Code Block history:transactionID "event.getTransactionID()"
DSpace Object resources
The DSpace Object which is the "subject" of the event always has properties:
Code Block rdf:type abc:Actuality
– its DSpace Object type, one of these URIs, which correspond to the DSpace Object type names:Code Block rdf:type dso:''ObjectType''
Code Block dso:Community
Code Block dso:Collection
Code Block dso:Item
Code Block dso:Bundle
Code Block dso:Bitstream
Code Block dso:EPerson
The DSpace Object which is the "object" of the event has properties:
Code Block rdf:type abc:Actuality
– its DSpace Object type.Code Block rdf:type dso:''ObjectType''
Optionally, both Object and Subject of the event may have these
properties if the data is available:
literal-titleCode Block dc:title
Handle-URICode Block abc:instanceOf
The EPerson Object which is the "participant" of the event has properties:
(Note that the email address of the EPerson is encoded in the URI)
– its DSpace Object type.Code Block rdf:type dso:EPerson
Binding between Handle and Object URI
Every DSpace Object with a Handle must record the mapping of that
Handle to an object URI (which might be identified only by the
database identifier in events before the Handle is assigned). This
is done with a statement on the object's DB-based URI relating it to
the Handle URI, e.g.
Code Block |
---|
1721.1/31429 |
, for example:
Panel |
---|
<info:dspace/dbid#item_814> abc:instanceOf <info:dspace/handle#1721.1/31429> |
<hr>
(OUTDATED) History Data Model
After examining the goals, the existing system, and similar designs such
as the PREMIS Event model, I've outlined this data model for
representing DSpace object history.
It is based on the current version (3) of
ABC Harmony as an RDF ontology.
The ABC Harmony model is reasonably close to what
I had in mind, and using an existing
ontology lets us leverage its documentation and examples.
The first-class objects are:
*Item, corresponds to the DSpace Item identified by a certain persistent identifier (i.e. Handle).
*Event, describes a change to another object.
*Archive, identifies a single instance of a DSpace installation.
*EPerson, names an individual agent responsible for an event.
There are also two "second-class" objects: Since these describe aspects
of Items that can change over time, they only appear in the context of
an Event that creates or modifies an Item.
*Bitstream, describes the aspects of a DSpace Bitstream object relevant to provenance.
*Metadata, a metadata item attached to an Item in the DSpace object model.
Item
The Item is a holder for the DSpace Item's only immutable property,
its persistent identifier (i.e. Handle). An Item is identified by
its Handle so it has the same identifier on every DSpace archive
where it is present.
It has the RDF type value
Code Block |
---|
dspace:Item |
,
which is a subclass of
Code Block |
---|
abc:Actuality |
.
An Item's URI is its persistent identifier in URN syntax, e.g.
Code Block |
---|
hdl:123456789/123 |
.
Archive
An Archive identifies the DSpace instance in which an Event occurs.
It is identified by the World Wide Web URL of its top-level page, e.g.
Code Block |
---|
http://dspace.mit.edu/ |
.
It has the RDF type value
Code Block |
---|
dspace:Archive |
, which is a subclass of
Code Block |
---|
abc:Actuality |
.
It also may contain the following Dublin Core properties:
*dc:title - Descriptive name of the archive, e.g. "Miskatonic University Digital Archive"
NOTE: This is just my naive interpretation of DC.
Metadata mavens and Dublin Core critics are invited to correct my
usage of these DC elements.
EPerson
An EPerson identifies, as precisely as possible, an agent authenticated
to the DSpace archive who was responsible for initiating an Event.
Its information may be of limited value for provenance,
since, in the DSpace architecture, an EPerson is defined only within
the context of an archive and is not given a persistent identifer.
The EPerson is identified by a combination of its home archive and
a cryptographic message digest of its attributes that are unique within
that archive (i.e. the email address). Its RDF type is
Code Block |
---|
dspace:EPerson |
,
which is a subclass of
Code Block |
---|
abc:Actuality |
.
It also may contain the following Dublin Core properties:
*dc:title - Personal name in canonical format, e.g. "Jack Florey".
*dc:identifier.uri - "mailto" URI containing email address, e.g. "florey@dspace.org"
NOTE: This is just my naive interpretation of DC.
Metadata mavens and Dublin Core critics are invited to correct my
usage of these DC elements.
Bitstream
Represents a bitstream added to an Item. It includes information that
may be relevant to the item's provenance (to cross-check the contents
of the archive against history later, for example).
A Bitstream only appears as the subject of statements belonging to a
"Situation" that is the result of an Event which created or modified an Item.
*rdf:type is
Code Block |
---|
dspace:Bitstream |
(a subclass of
Code Block |
---|
abc:Actuality |
).
*dc:identifier.uri - The SequenceID of the bitstream, e.g. "#1"
*dc:title - the name attribute of the bitstream, e.g. "thesis.pdf"
*dc:format - short name of BitstreamFormat, e.g. "Adobe PDF"
*dc:format.extent - size in bytes of the contents, e.g. "314592"
*dc:type - type or purpose; i.e. name of the bundle containing bitstream, such as "ORIGINAL".
*dspace:checksum-algorithm - name of checksum algorithm, e.g. "MD5"
*dspace:checksum - value of checksum of bitstream contents, e.g. "6df9d97f2e8f9.."
Metadata
This represents one metadata value belonging to an Item.
When an item has multiple values for the same metadata element/qualifier,
they appear as separate nodes in the RDF model, not as multiple values within one node.
Metadata only appears as the subject of statements belonging to a
"Situation" that is the result of an Event which created or modified an Item.
It may have the following properties:
*rdf:type is
Code Block |
---|
dspace:Metadata |
(a subclass of
Code Block |
---|
abc:Actuality |
).
*dspace:mdSchema - the metadata schema (default is "dc").
*dspace:element - name of the Dubln Core-styled field identifier.
*dspace:qualifier - qualifier of the Dubln Core-styled field identifier.
*xml:lang - language code, e.g. "en".
*dspace:value - value of the metadata field.
Since DSpace metadata is traditionally in Qualified Dublin Core fields,
there is a shorthand for listing these. The Metadata value only needs
the appropriate DC or QDC property, whose value is the metadata value,
and the optional
Code Block |
---|
xml:lang |
property, e.g. (in N3 format):
Panel |
---|
... |
Event
The purpose of the history system is to record "events", so the Event is
its central data structure. The history record is simply a collection
of Events. Each Event represents a change to an Item – although each
transaction on the DSpace server may result in more than one Event being
recorded.
Each event has the following properties:
- The subject URI consists of the archive's URI followed by a locally-unique identifier for the Event.
*rdf:type is
*abc:hasParticipant - value is the EPerson object who was the authenticated user responsible for this change.Code Block abc:Event
*abc:creates | abc:hasResult | abc:destroys - identifies the type of action, the value is the URI of the affected Item.
*abc:atTime - Timestamp at which the event was logged, e.g.
*abc:precedes - Optional, this refers to theCode Block "Tue Jan 24 17:46:49 EST 2006"
that results from this action. It is a blank node that describes the details of what was changed.Code Block abc:Situation
*abc:involves - Value is the URI of the DSpace archive in which this event occurred.
Situation
In the
ABC Harmony
model, a Situation descibes the "existential" (i.e. time-varying) aspects of
an Actuality at a certain point in time. The alterations to the state
of an Item after an Event make up a Situation that the Event precedes.
(They are connected by the
Code Block |
---|
abc:precedes |
property, which says the Event
precedes the Situation.)
*rdf:type is
Code Block |
---|
abc:Situation |
*abc:contains - value is
Code Block |
---|
Bitstream |
or
Code Block |
---|
Metadata |
added to the Item at this time.
*abc:removes - value is
Code Block |
---|
Bitstream |
or
Code Block |
---|
Metadata |
deleted from the Item at this time.
NOTE: There is actually no
Code Block |
---|
removes |
property in the ABC Harmony ontology,
but there is nothing else equivalent so we are taking the liberty of
adding it.
</html>