Thursday, January 31, 2008

How Shall I Integrate Thee? Let Me Count the Ways...

Leigh Dodds has a nice post How Shall I Integrate Thee? Let Me Count the Ways... about different ways to integrate data.
  • The one where we share identifiers
  • The one where we're describing the same thing
  • The one where we're speaking different languages
  • The one where we're using different units
  • The one where we're speaking at different levels of abstraction

Apart from the suggestion that Leigh has been watching way too much Friends, there's much food for thought here. I suspect that "The one where we're describing the same thing" is the one I'll be making most use of.

In Rethinking LSIDs versus HTTP URI I argued that most applications will use HTTP URIs, which makes them accessible, but not terribly useful as identifiers, the reason being that I think it is unlikely that people will reuse HTTP URIs ("The one where we share identifiers"). A good example is Connotea, which has its own URIs for each paper its users bookmark. I won't use these URIs as identifiers in my database (if only because if a user resolves them, they get taken to Connotea's web site, not mine). However, I will store any PubMed and DOI identifiers, so that somebody aggregating information from Connotea (say to retrieve user tags) and my database (say, to get links to sequences and specimens) can work out that the Connotea URI and my URI are talking about the same thing.

Tuesday, January 29, 2008


Time for a rant. I spend a lot of time fussing with records from sources such as GenBank and DiGIR providers, trying to extract strings that might be identifiers, with a view to linking sequences to specimens (and thus to localities), sequences to publications, publications to GUIDs, etc. The goal is to be able to link all these resources together, so that I can go seamlessly from a phylogeny in TreeBASE to a locality on a map, and visa versa, of from a phylogeny for a parasite to that of its host, for example.

Time and again I come across extraordinarily frustrating messes. More and more I see why Cory Doctorow wrote Metacrap. According to this essay, the problems with metadata are:
  1. People lie
  2. People are lazy
  3. People are stupid
  4. Mission: Impossible -- know thyself
  5. Schemas aren't neutral
  6. Metrics influence results
  7. There's more than one way to describe something

Amen. I know I've moaned about this before (e.g., Damn DiGIR, and AMNH Dspace and Openurl), but it's just amazing what people put into databases.


My current favourite is the junk that populates GenBank source records. This is where people provide information about the source of their sequence (e.g., the organism it came from, any voucher specimens, and the geographic locality of the source). All manner of junk ends up here.

You'd think that geographic location was a straightforward thing to record, but no. Consider sequence AY281248. The country field for this record is:
Australia: Gubbata, NSW (GPS: 33 38' 07'', 146  33' 12'')

Spot the problem? Leaving aside the fact that somebody has to parse this and extract the latitude and longitude (hmm, which one is which, can I rely on latitude coming first, ah the second must be longitude because latitude is never > 90°), the co-ordinates are not in Australia.

View Larger Map

Last time I checked, Australia was in the southern hemisphere, and not drifting of the coast of Japan. Now, latitude 33°38' 07''S is in Australia:

View Larger Map

Seems like a small deal to leave off "S" (or a minus sign), but changing hemispheres is a big deal. Then there are strings such as
Nicaragua: Rio San Juan, Near Isla de Diamante 
(ca. 15 km SE El Castillo on Rio San Juan), 10deg56'N 84deg18'W

from DQ502492. Sigh.

Now, you might say that this isn't GenBank's fault, because the country field wasn't supposed to have latitude and longitude information, that is the role of the lat_lon field. This format for this field is defined as:
degrees latitude and longitude in format "d[d.dd] N|S d[dd.dd] W|E"

Fine, but people don't always follow this format. For example, DQ226041 has
/lat_lon="6 28.06'N; 58 37.16'W"

Not hugely different, but the ";" needs to be removed before parsing. What's worse, I can't assume people will follow GenBank guidelines about how to store data in these fields.

Specimen codes

What I'm really after are specimen codes, as these can potentially be linked to digital records served by natural history collections. But, once again all manner of variations end up in GenBank records. For example, specimens in the Field Museum can be referred to as Field Museum of Natural History 167358 (DQ023431) or as FMNH 167358 ( AY324464 ), and there are other variations I've come across as well. Furthermore, FMNH 167358 isn't enough by itself to retrieve a record from the Field Museum, I need to know the address of the DiGIR provider, and whether the specimen is a mammal or some other vertebrate (museum specimen codes are often not unique across the institution). In my opinion the single biggest failure of specimen digitisation efforts is the lack of a globally unique, resolvable identifier. Sure, it's coming, but in the meantime we have chaos.

Tools like GBIF show us what can be done when we aggregate lots of specimen records, but I'd argue the real fun starts when we link resources together, and we can only do this is we have stable, shared identifiers. As an example, Steppan et al. (2003) (doi:10.1111/j.1095-8312.2003.00274.x) published a study of Apomys biogeography. If I get a sequence from this study from GenBank (e.g., AY324464 mentioned above) I have a GenBank record with very few links. There's no PubMed record, for example. If I use an OpenURL resolver (such as the one I wrote for bioGUID) I can retrieve a DOI from the citation Biol. J. Linn. Soc. Lond. 80 (4), 699-715 (2003). This gives me a GUID for the paper, as well as a way to link to the text. The specimen code FMNH 167358 can be used to retrieve details from the Field Museum (once I've parsed the GenBank taxonomy string to discover that Apomys datae is a mammal). This gives me the latitude and longitude of the locality from which the specimen was collected, so I can put it on a map:

View Larger Map

So, I've added information to the GenBank record. But this isn't really the goal. What I want to do is link these elements together. For example, here's a graph showing the link between the publication, the sequence, and the specimen:

Basically, this is the immediate neighbourhood of the sequence AY324464. If I get the neighbourhood of the specimen:

Note that this includes another sequence, DQ023431 (the "tag" refers to the uBio record for Apomys datae -- I treat taxonomic names as tags, but that's another story). I could then navigate to DQ023431, and then onto the publication that refers to that sequence, and so on. Very quickly we get a web of data. This is, of course, the vision of the Semantic Web and related projects, such as Linking Open Data. Wonderful idea, it's just such hard work getting there...

Saturday, January 26, 2008

EDIT meeting

Spent the week in Portugal at the EDIT Future Trends of Taxonomy meeting, held at the View from cave, at the beach in front of the Hotel Tivoli Almansor, Carvoeiro. Pretty venue, and an interesting conference (for the sociology, if nothing else).

What I did find fascinating was the local geology, especially what appear to be ancient rock pools several metres above the existing sea level. These can be seen around Algar Seco. The pools are deep, often with smooth edges ground by rocks, some of which are still lying in the centre.
Looks like the sea level here was once several metres higher. When I have a chance I should follow this up (e.g., doi:10.1016/j.geomorph.2006.04.014).