Bob,
Thanks for the explanation.
Excuse my lack of knowledge about this--but I trying to understand this in a way that taxonomists like myself will need to (and I need to understand it in terms that I can use to explain it to other taxonomists). So much of what we are doing now in TDWG is so foreign to taxonomists, and I fear that you are going to completely leave us (even those of us who are 'relatively technically inclined' behind--which I don't think is helpful.
Your explanation does help (though I think my calling it a parent LSID vs. resolving to something in RDF is somewhat semantic--if the resolver does not allow all of the things mentioned in 1-7 (and so on) to resolve to the same "something" that relates them all to the same 'parent' (a term that taxonomists will understand) specimen it really isn't going to work--but I assume that you CS guys have that sorted and I just need to read and ask more questions so that I can translate it somehow into terminology that I and other taxonomists understand).
So, to follow on that line: 'all' we, in INOTAXA, have to do is assign LSIDs within INOTAXA (temporarily at least); that we come up with the ontology for that in the Taxonomic literature interest group (but I assume that it will be better if they are similar to those for similar objects described by every other interest group since nearly everything that we will assign LSIDs to will relate to other interest groups); and that the resolver, once we have all this designed will be able to relate all of the things I referred to together?
Finally, what does what you just said mean that Rich's question about whether the LSID applies to the specimen or the data record that describes it? Following your logic, isn't it really better if we think of them each as having an LSID and making sure that we can bring all of them together somehow? Or, perhaps the specimen does not have an 'official' LSID, but it should have some sort of GUID that allows the institution that holds them to link the specimen to the record that has the LSID (if only that were true--our Entomology Dept. gave up requiring GUIDs on specimens that match to records in the database--even for types--years ago and are only now starting to see that this was not a wise decision!). In the latter case, clearly Rich needs to think of the LSID as applying to the record and not to the specimen, correct?
Thanks, Anna
Anna L. Weitzman, PhD Botanical and Biodiversity Informatics Research National Museum of Natural History Smithsonian Institution
office: 202.633.0846 mobile: 202.415.4684 weitzman@si.edu
________________________________
From: Bob Morris [mailto:morris.bob@gmail.com] Sent: Sat 02-Jun-07 3:29 PM To: Weitzman, Anna Cc: Richard Pyle; Paul Kirk; Jason Best; tdwg-guid@lists.tdwg.org Subject: Re: [tdwg-guid] First step in implementing LSIDs?[Scanned]
On 6/2/07, Weitzman, Anna WEITZMAN@si.edu wrote:
[... 7 examples omitted]
Either each of these (1-7) will need to have its own LSID (or an equivalent in the case of the specimen itself) or they will all need to have the same LSID. If the former, they will all have to resolve to the same parent LSID--is this for the specimen or the record in its home database?--in order for the overall biodiversity information system to really work.
Two different objects cannot have the same LSID by definition. [This is more or less the sole overarching point of GUIDs].
I don't know what is meant by "parent LSID", but TDWG requires that an LSID resolution service return its metadata in RDF, the Resource Description Framework semantic web language. By its design, RDF is especially good at expressing relations between things it describes, so there is plenty of room for the LSID metadata to express whatever relations between these examples each of its resolution services might wish to. Furthermore, the emergent TDWG ontology standards (see TDWG-TAG) support some particularly convenient ways to do this, should the various interest groups be motivated to visit this question. That would be Good Thing, so that different resolvers of similar objects might actually offer similar, or at least as to relations, easily comparable, metadata. Still, each subgroup is likely to need to thrash these issues out separately. The TCS group is historically ahead of everybody else in this regard, since they expressed a fixed set of relations among Taxon Concepts more or less ab initio.