eDiscovery Daily Blog
The Importance of Metadata – eDiscovery Best Practices
This topic came up today with a client that wanted information to help justify the request for production from opposing counsel in native file format, so it’s worth revisiting here…
If an electronic document is a “house” for information, then metadata could be considered the “deed” to that house. There is far more to explaining a house than simply the number of stories and the color of trim. It is the data that isn’t apparent to the naked eye that tells the rest of the story. For a house, the deed lines out the name of the buyer, the financier, and the closing date among heaps of other information that form the basis of the property. For an electronic document, it’s not just the content or formatting that holds the key to understanding it. Metadata, which is data about the document, contains information such as the user who created it, creation date, the edit history, and file type. Metadata often tells the rest of the story about the document and, therefore, is often a key focus of eDiscovery.
There are many different types of metadata and it is important to understand each with regard to requesting that metadata in opposing counsel productions and being prepared to produce it in your own productions. Examples include:
- Application Metadata: This is the data created by an application, such as Microsoft® Word, that pertains to the ESI (“Electronically Stored Information”) being addressed. It is embedded in the file and moves with it when copied, though copying may alter the application metadata.
- Document Metadata: These are properties about a document that may not be viewable within the application that created it, but can often be seen through a “Properties” view (for example, Word tracks the author name and total editing time).
- Email Metadata: Data about the email. Sometimes, this metadata may not be immediately apparent within the email application that created it (e.g., date and time received). The amount of email metadata available varies depending on the email system utilized. For example, Outlook has a metadata field that links messages in a thread together which can facilitate review – not all email applications have this data.
- Embedded Metadata: This metadata is usually hidden; however, it can be a vitally important part of the ESI. Examples of embedded metadata are edit history or notes in a presentation file. These may only be viewable in the original, native file since it is not always extracted during processing and conversion to an image format.
- File System Metadata: Data generated by the file system, such as Windows, to track key statistics about the file (e.g., name, size, location, etc.) which is usually stored externally from the file itself.
- User-Added Metadata: Data created by a user while working with, reviewing, or copying a file (such as notes or tracked changes).
- Vendor-Added Metadata: Data created and maintained by an eDiscovery vendor during processing of the native document. Don’t be alarmed, it’s impossible to work with some file types without generating some metadata; for example, you can’t review and produce individual emails within a custodian’s Outlook PST file without generating those out as separate emails (either in Outlook MSG format or converted to an image format, such as TIFF or PDF).
Some metadata, such as user-added tracked changes or notes, could be work product that may affect whether a document is responsive or contains privileged information, so it’s important to consider that metadata during review, especially when producing in native format.
Here’s an example of one case where the production of metadata was ordered and an answer to the question “Is it Possible for a File to be Modified Before it is Created?” (you might be surprised at the answer).
So, what do you think? Have you been involved in cases where metadata was specifically requested as part of discovery? Please share any comments you might have or if you’d like to know more about a particular topic.
Disclaimer: The views represented herein are exclusively the views of the author, and do not necessarily represent the views held by CloudNine Discovery. eDiscoveryDaily is made available by CloudNine Discovery solely for educational purposes to provide general information about general eDiscovery principles and not to provide specific legal advice applicable to any particular circumstance. eDiscoveryDaily should not be used as a substitute for competent legal advice from a lawyer you have retained and who has agreed to represent you.
CloudNine empowers legal, information technology, and business professionals with eDiscovery automation software and professional services that simplify litigation, investigations, and audits for law firms and corporations.