On the subject of document metadata, colleagues in the US with time to
read it might be interested in an much quoted Australian case
supporting the admissibility of electronic documents in evidence heard
in the New South Wales Supreme Court (Asic  v  Rich  [2005] NSWSC 417
(5 May 2005)). In this specific case, the Properties element of
spreadsheets stored on a network drive was discussed at great length.

The text can be found at this URL:
http://www.austlii.edu.au/cgi-bin/sinodisp/au/cases/nsw/NSWSC/2005/417.html

Here are some extracts:

12 The finance directory of the I:/Drive contains nearly 25,000 files.
Counsel demonstrated the operation of the I:/Drive in court. ...

13 The documents tendered ... include "properties pages", about which
there has been contention. In his affidavit made on 13 September 2004,
Mr Bannister briefly explained properties pages. He said that
Microsoft Windows automatically generates and updates "properties"
information for computer files created using Windows applications such
as Microsoft Excel and Microsoft Word .... He continued:
"The 'properties' information includes time and date 'stamps' which
automatically record when a particular file is created, modified,
accessed or printed by reference to the setting of the relevant
computer's internal electronic clock. The date a file is 'created'
refers to the date that a file is saved under a particular name or the
date that a particular file is copied. Thus the file properties may
show that a file was 'created' after it was 'last modified'. A user
may view the 'properties' of a file by navigating to a 'properties'
page for that file...".

14 In the tendered documents  ... two properties pages (were
provided), one being the "General" page and the other being the
"Statistics" page. The copies of the properties pages provided ...
appear to be superimposed on the first page of the document to which
they relate, and this makes it plausible to infer that the properties
page relates to that document. But sometimes this correlation does not
appear to be established, or the properties page is illegible.

15 In (one) case ... a different kind of property page was produced,
entitled "Summary", which identified the "author". Mr Bannister did
not explain whether the "author" is the person who "created" the
document or "modified" it or "last saved" it.

16  (It was) submitted that the properties pages are an integral part
of each document in electronic form, but Mr Bannister's evidence does
not go so far. What he suggests is that one "navigates" from the file
to the properties pages. I infer that if one carries out the
navigation correctly, the properties pages that are reached are the
properties pages for the file from which one launched the navigation.

17 It seems to me that, although the "created" and "author" boxes are
problematic for reasons given, and the "modified" box is unhelpful to
the extent that the author of the modifications and the nature and
content of the modifications are not indicated by it, the "last saved
by" box is some utility for documentary tender purposes, provided
there is evidence linking the properties page containing that box with
the document in question. I have taken it into account in those cases
where the link between the properties page and the document is
apparent. But the prerequisites for tender and admissibility can be
established in other ways, where the properties pages do not assist or
have not been tendered.

Regards
Andrew Warland
Sydney, Australia
(My views entirely)

On Thu, Nov 5, 2009 at 5:01 AM, Larry Medina <[log in to unmask]> wrote:
>>
>>Metadata is produced as part of systems, and depends on the parameters of
> the system.  Sometimes its good information and sometimes its confusing.
> I'm thinking particularly of audit histories which can be accurate but can
> also give erroneous and mixed messages.  If the courts accept metadata as
> record they are also going to have to look into the systems that produce the
> metadata and how those systems function to produce metadata.
>>
>
> I'm not sure that the courts are going to have to look into it, the burden
> will be placed on the parties involved in the meet and confer to explain to
> the court the challenges and effort required to additionally provide the
> metadata and the concerns relative to what it represents and how it can
> easily be misinterpreted.
>
> The court acts as a sounding board in these meetings and will make a ruling
> based on how well the arguments are presented by the two parties what is
> adequate to meet the needs of each party and what may be deemed over
> burdensome, and if one party still wants that, then they will have to pay
> for it to be gathered and presented.
>
> The concern here is as mentioned earlier, metadata isn't "bot generated" and
> it all doesn't reflect the same things... it's highly subjective and can be
> interpreted in ways that it can be beneficial or harmful, and it doesn't
> take willful manipulation to make that happen.  As stated in the initial
> post, it can be as simple as a bad clock in a system, transfer of files in
> the course of normal business to new systems, files created/edited for
> senior staff by administrators, any number of legitimate business reasons
> that will make metadata reflect incorrect information to establish "intent"
> or "actions" taken with respect to a record.
>
> I understand what you (and others) have said that it's inherent content
> related to electronically produced documents and records, but to go back to
> the example of what you provide to support the validity and authenticity of
> a paper format document/record, nothing is subject to the same level of
> questioning.
>
> Will an attorney potentially have to argue that "Mr. X couldn't have
> generated that document on Oct. 31st at 2:31pm in Boston because he was in
> Jakarta and I can produce the GPS records to support that from his
> Blackberry associated with a phone call he made at the same time" ?   That
> doesn't say that Mr. X hadn't talked to his assistant a day earlier and
> asked him/her to prepare a document saying blah, blah, blah for his review
> and signature and it actually WAS generated on a device that applied
> metadata attributing it to him... but can you imagine having to go to that
> level potentially for every item provided in a request that has metadata
> associated with it?
>
> Every organization would need to determine what is automatically collected
> through applications, and what is additionally applied by systems on
> capture... when a document is created, drafted, revised, finalized, and
> ultimately transferred to an RMA, different metadata is applied each time.
> They would additionally need to have documentation supporting what the
> metadata is intended to represent, and have documented business practices to
> support scenarios where work is done on behalf of individuals by others
> (support staff) to explain why the metadata may have a different name or
> node associated with it.  They would need to validate system and desktop
> 'clocks' to ensure they are in step with each other so documents/records
> reflect accurate dates and times that are consistent with one another.
>
> And how do you address things like an MS Office file opened up at 8:13am,
> someone starts working on it, get a phone call, does something else, leaves
> the document open, works on it for awhile, goes off to a meeting at 1:15,
> leaves it open, gets tied up, goes home at 6:00 and finishes it the next
> day?   Should this matter?  Maybe not, but the metadata will indicate that
> someone worked on the document for 24 hours, made x keystrokes, etc. and if
> this document is called into question at sometime in the future, someone
> will have to explain they went to meetings, took calls, went home and failed
> to close the document, all because the metadata accurately reflected
> inaccurate information.
>
> Is this the future of RIM?  If so, the pay better improve drastically... and
> soon.
>
> Larry
> [log in to unmask]
>
>
>
> List archives at http://lists.ufl.edu/archives/recmgmt-l.html
> Contact [log in to unmask] for assistance
> To unsubscribe from this list, click the below link. If not already present, place UNSUBSCRIBE RECMGMT-L or UNSUB RECMGMT-L in the body of the message.
> mailto:[log in to unmask]
>

List archives at http://lists.ufl.edu/archives/recmgmt-l.html
Contact [log in to unmask] for assistance
To unsubscribe from this list, click the below link. If not already present, place UNSUBSCRIBE RECMGMT-L or UNSUB RECMGMT-L in the body of the message.
mailto:[log in to unmask]