In response to the recent query from Mr Stavrakis:

I am not entirely clear whether the question is about the changes between 
that document and its earlier incarnation explained in the introduction, so 
have had to try to answer both in this email.  There has been a significant 
hiatus in the development of the eGovernment Metadata Standard over the 
past 18 months and this has impacted on this work [more about that later].  
First off, you should be aware that the 2004 version of the metadata 
standard referred to is still a draft so I suggest you might not want to 
conduct research about its implementation.  That is why it is hosted on 
GovTalk and not on TNA's own website, as well as to prevent confusion with 
the software testing activity of TNA.  In aiming now to incorporate PREMIS 
[among other current issues - see below] we shall have to amend it before 
finalising and we also have to resolve some issues relating to its 
positioning within wider eGovt standards.


The following information - apart from the very end bit - relates to the 
version that accompanies the Functional requirements for records management 
sytems, finalised in 2002.  

The first thing to remember is that this work is about interfaces (we use 
the term "presentation"), not necessarily how metadata should be held in a 
system.

The main thinking behind this work is, quite frankly, empirical.  Namely: 
squaring the work we had already done on defining generic requirements for 
electronic records management with wider government agendas on metadata 
(inevitably DCMI-derived), interoperability and eGovernment and the 
ISO15489 view of the world.  [There is discussion of this in the 
introduction to the document itself].  

We worked from the presumption that digital objects being so prone to 
change, a full range of metadata supporting and recording the trusted 
processes of a records management system is required.  Ultimately it 
amounts to something close to a record carrying its audit trail around with 
it and potentially in sufficiently open a way to allow it to continue to be 
used to manage it until [and even beyond] disposal.  Others have aimed at 
producing more limited metadata sets - notably the two sets of baseline and 
benchmark requirements proposed by the InterPARES project - but these are 
for more specific archival reproduction and certification purposes and 
based on a particular archival viewpoint.

Behind our work, though, at various stages of remove is similar work done 
in the Australian Commonwealth that ultimately stems from the Records 
continuum viewpoint and particularly the work of the SPIRT project and the 
wider Monash University suite of research projects.  The thinking being 
that there are potentially severe evidential problems with not having this 
level of accountability for our RM / archival processes.

Exactly how this should be done is actually a moot point.  The Monash model 
assumes multiple conceptual entities, only one if which is the "Record".  
(The others are mandate, agent, business process).  I think it is true to 
say we all have to manage with a "record centric" view of the world - 
pragmatically this is the main entity that people think requires managing 
and is worth spending money on manifesting.  This gives some awkwardness: 
how do we also represent the other entities in metadata?

This explains a few of the slightly quirky-looking aspects of the metadata 
standard and some of the semantic awkwardnesses caused by integrating 
process metadata into the wider eGMS.  DC rules require things like the 
dumbing down rule to be observed: this can't be done if the metadata is at 
one stage removed from the information resource (record) because it relates 
to a process applied or to be applied to the record rather than the entity 
itself.


There remain some issues that need further work:

More work on Preservation metadata (we intend to incorporate the 
consequences of PREMIS, but this means going to sub-sub elements.  This 
gives attributes of format, but there is also preservation process metadata 
to be considered);
Working through some areas of semantic strain caused by an overenthusiastic 
mapping to the DCMES (Cabinet Office had already endorsed this without 
thinking of all the implications beyond resource description);
Mappings into archival description;
The precise form of the machine readable representation (Schema / RDF / 
whatever?) ; draft schemas are on GovTalk by the way.

This type of metadata is complex and needs to have the potential to work 
in - or be transformed into metadata for - other domains, such as 
discovery.  We made a series of compromises for good reasons, but some of 
them may need slight tweaking in the near future.

At the same time, the internal structure and management of the eGovernment 
Metadata Standard has been under review by the eGovernment Unit for the 
past year.  Hopefully we can tease all this out and address these new areas 
soon.  It is true that a more direct injection of some of the concepts from 
Australia might have prevented some of these problems arising, but we live 
and learn.

Your main references perhaps ought to be

SPIRT work and its follow on (the "Clever Recordkeeping metadata project")
ISO23081/1 (and /2 when it appears; for what it is worth I have represented 
TNA / UK in this work on the ISO Committee)
The InterPARES1 report
PREMIS report
Proceedings of an ErpaNET workshop on metadata in preservation in Marburg, 
September 2003


returning to your questions:

I repeat the 2004 document is a draft.

As this work is about interfaces and all the corners of it are still being 
worked out, I am not sure it is worthwhile examining the impact.  One thing 
it has definitely achieved is a greater level of understanding about 
records management metadata on the part of the vendor commmunity and 
probably practitioners also.  This, though, still has to mature further.

We now have proprietary systems in the UK marketplace that can recognise 
file formats, capture metadata about them and export it: probably just the 
headline 'format' at present.  This needs to be levered up so the other 
attributes of format can also be captured and so the format information 
complies with a unique system of format identification such as that being 
devised for PRONOM.  Then we shall move onto preservation process metadata.

Many of the experiences with implementing can only truly be had when 
records created using such standards are a number of years old and need to 
be moved to other systems, including archival systems.  We hope and expect 
to have resolved the semantic and syntactic issues and the machine readable 
ones too by then.

I hope this helps.

Malcolm Todd
Head of Standards, Digital Records Management
The National Archives, Kew

http://www.nationalarchives.gov.uk