Metadata: Oh - The Pain!

If you really want to scare away scientists from your project, say: "metadata". Most scientists develop a skin rash on having to deal with metadata, yet useful information systems depend on metadata of some form or other. Many metadata are straight forward and can be generated from context. The most difficult metadata elements seem to be keywords.

Isn't there a way to generate metadata automatically? Well, there are methods proposed and there are some tools around for automatic metadata extraction. With less guesswork involved, the extraction process can be made more efficient. Therefore it is also useful to know which metadata can be embedded in which file formats.

A report by Polfreman and Rajbhandari, published last week in the JISC information environment repository. The extensive report looks at methods and tools for automated metadata generation, mainly from the angle of generating Dublin Core metadata for institutional repositories.

Polfreman, Malcolm, und Shrija Rajbhandari (2008), MetaTools - Investigating Metadata Generation Tools , JISC, London, United Kingdom. [online] Available from: http://ie-repository.jisc.ac.uk/258/

Robert has already looked at the tool offered by Yahoo! and considers it potentially useful for Stratigraphy.net. We'll keep you posted on any progress we make with automated metadata extraction.

Dublin Core for stratigraphic units

This is a first draft which shows how I would encode metadata on stratigraphic units.
The usage of the coverage and subject (which both now contain the chronostratigraphic position of the unit) tag is still preliminary. I have to look up the DC specifications, as far as I remember there was the possibility to specify spatial as well as temporal coverage..

<metadata>
<oai_dc:dc xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/oai_dc/ http://www.openarchives.org/OAI/2.0/oai_dc.xsd">
<dc:format>text/html</dc:format>
<dc:rights>
Licensed under a Creative Commons Attribution 2.5 License
</dc:rights>
<dc:publisher>
Stratigraphy.Net http://www.stratigraphy.net</dc:publisher>
<dc:type>Stratigraphic Unit</dc:type>
<dc:title>Ammergauer Schichten</dc:title>
<dc:date>1855</dc:date>
<dc:creator>Studer</dc:creator>
<dc:identifier>http://some_URL</dc:identifier>
<dc:relation>Wetzstein-Schichten</dc:relation>
<dc:subject>Malm</dc:subject>
<dc:coverage>Malm</dc:coverage>
<dc:coverage>Germany</dc:coverage>
<dc:coverage>Ammergebirge</dc:coverage>
</oai_dc:dc>
</metadata>

TaxonConcept's Taxon Concepts II

Well, it is done ;) Here is an example which shows how our TCS XML looks like:
http://taxonconcept.stratigraphy.net/taxon_tcs.php?taxid=792

TCS seems to be really the XML standard to describe TaxonConcepts synonymy list entries.
The only open problem is how fine the granularity of a data set should be. I have now included any synonymy list of a distinct taxon in one TCS file. So our TCS granularity is at the taxon level. A finer granularity at he synonymy list level however also seems to be reasonable.

Dublin Core for Taxa

I recently wrote here that TaxonConcept will soon offer its metadata in TCS (Taxon Concept Schema) format to improve data exchange and interoperability with other groups. As the planned exchange interface will be a Open Archives (OAI) provider, we also have to deliver our data in Dublin Core (DC) format.
This brought up the problem how taxonomic data should be encoded in DC, which is mainly designed for document, electronic ressources and similar entities.
I had a short discussion with some of the members of the TDWG GUID list and decided to treat taxa similar to museum objects. For physical objects DC fields creator and date should contain e.g.the artist's name and date of creation instead of the name of the creator and publishing date of the electronic metadata representation. Therefore, I decided to use the creator tag for the taxon author, the date field as the date of description of the taxon and the title field for the taxon name. To describe the classification of a taxon I'll use the subject tag. Further, the relation tag will be used to handle the information TaxonConcepts stores from published synonymy lists.
An example:

<metadata>
<oai_dc:dc xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/oai_dc/ http://www.openarchives.org/OAI/2.0/oai_dc.xsd">
<dc:format>text/html</dc:format>
<dc:format>application/pdf</dc:format>
<dc:rights>
Licensed under a Creative Commons Attribution 2.5 License
</dc:rights>
<dc:publisher>
Stratigraphy.Net http://taxonconcept.stratigraphy.net
</dc:publisher>
<dc:type>Taxon Concept</dc:type>
<dc:title>Eoglobigerina edita</dc:title>
<dc:date>1953</dc:date>
<dc:creator>Subbotina, N.N.</dc:creator>
<dc:identifier>
http://taxonconcept.stratigraphy.net/taxon_details.php?taxid=787
</dc:identifier>
<dc:relation>Globigerina edita Subbotina 1953</dc:relation>
<dc:relation>Globorotalia (Globorotalia) edita Subbotina 1953</dc:relation>
<dc:relation>Eoglobigerina edita edita Subbotina 1953</dc:relation>
<dc:relation>Globigerina edita var. polycamera Khalilov 1956</dc:relation>
<dc:relation>Eoglobigerina edita polycamera Khalilov 1956</dc:relation>
<dc:relation>
Globigerina (Eoglobigerina) hemisphaerica Morozova 1961
</dc:relation>
<dc:relation>
Globigerina (Eoglobigerina) tetragona Morozova 1961
</dc:relation>
<dc:relation>
Globigerina (Eoglobigerina) pentagona Morozova 1961
</dc:relation>
<dc:relation>
Globigerina (Eoglobigerina) theodosica Morozova 1961
</dc:relation>
<dc:relation>Globanomalina pentagona Morozova 1961</dc:relation>
<dc:subject>Eukaryota</dc:subject>
<dc:subject>Protoctista</dc:subject>
<dc:subject>Granuloreticulosa</dc:subject>
<dc:subject>Foraminifera</dc:subject>
<dc:subject>Globigerinida</dc:subject>
<dc:subject>Globigerinaceae</dc:subject>
<dc:subject>Globigerinidae</dc:subject>
<dc:subject>Eoglobigerinidae</dc:subject>
<dc:subject>Eoglobigerina</dc:subject>
<dc:subject>Eoglobigerina edita</dc:subject>
<dc:subject>Acarinina nitida</dc:subject>
</oai_dc:dc>
</metadata>

TaxonConcept's Taxon Concepts

Currently, TaxonConcept's data exchange capabilities are quite limited. This is mainly because we have not been able to determine a appropriate XML format which would allow us to represent the majority of TaxonConcepts information categories such as, concepts, descriptions, links to image objects, references etc.
Commonly used formats such as DarwinCore and ABCD are mainly designed to represent metadata of collection objects or species observation data and therefore not suited for our purposes. But at least TC's most important information pieces the taxonomic concepts and references can be represented fairly good by the TDWG standard TCS (TaxonConcept transfer schema).
According to this TDWG standard, a Taxon Concept is a name plus a description of a taxon, a definition which fits perfectly to what we do:
The taxonomic concepts stored in TC are entries of published synonymy lists. These basically represent definitions of individual taxonomic opinions by including or excluding other author's descriptions. In other words, a synonymy list is a Taxon Concept, which includes other Taxon Concepts.
The most difficult part when we start to translate our data to TCS will be the translation of 'Open Nomenclature' to TCS. Fortunately, TCS allows to represent our synonymy list entries as concept relationships, pro parte relationships (p) as well as misapplied names (non). which should enable us to create sufficient XML representations of our data.