In the spirit of self-clarification as demonstrated by Bob (with whom I agree on this issue of LSID spec/etc.), I should point out the following:
Rich said 'The LSID spec accomodates such objects in the form of "data-less" LSIDs -- that is, LSIDs with zero "data" content (only metadata).'
Rich should have said 'The LSID spec accomodates such objects in the form of "data-less" (my term) LSIDs -- that is, LSIDs with zero "data" content (only metadata).'
Rich did not mean to imply, through use of quotation marks, that the term "data-less" is included in the LSID spec. The words used in the spec (if I remember correctly) are "conceptual" and "abstract", which I believe are used in the LSID spec synonymously. I avoid the term "conceptual" like the plague, because inevitably it is interpreted by some as "LSIDs applied to taxon concepts". And though less of a problem, I'm worried that some might interpret "abstract" as "LSIDs applied to abstractions of data objects", or maybe "LSIDs applied to publication objects, for which only the Abstract is returned". The term "data-less" seems to cut striaght to the chase, and is not (to my knowledge) homonymous with anything else in our usual lexicon.
Aloha, Rich
Richard L. Pyle, PhD Database Coordinator for Natural Sciences and Associate Zoologist in Ichthyology Department of Natural Sciences, Bishop Museum 1525 Bernice St., Honolulu, HI 96817 Ph: (808)848-4115, Fax: (808)847-8252 email: deepreef@bishopmuseum.org http://hbs.bishopmuseum.org/staff/pylerichard.html
Please, let's not get bogged down in alternate definitions of the word "data" and "metadata". I swear, the single greatest impediment to progress in biodiversity informatics (by far) in my opinion has been human-language semantics. I had to qualify the word "semantics" in the previous sentence with "human-language", because even the very word "semantics" has more than one meaning in our conversations (I almost used the word "vocabulary" instead of "sematics", but of course that word, too, has another meaning within our various conversations). We could fill a small dictionary with words that have more than one meaning in different contexts ("concept", "type", "class", "synonym", and worst of all, "name" -- among many others).
So, when we speak of "data" and "metadata" in the context of LSIDs, let us please use those words specifically in the context of their well-defined meaning as related to LSIDs.
And in this LSID sense of the word "data", many of our objects (taxon names, taxon concepts, locality descriptions, specimens, agents, bibliographic citations, etc.) simply have no "data", because none of these things have any inherent digital manifestation. We could concatenate what would otherwise be LSID-metadata for one of these non-digital objects (e.g., a database record) into a single byte-stream, and define this as "data" tied to a particular LSID, but then a new LSID would need to be issued everytime someone wanted to change that bytestream (e.g., convert it from ASCII to UNICODE, or change the meaning, rendering, or content of one of the concatenated metadata elements). For this, and other reasons, I think this is a bad approach.
Instead, I think we should embrace LSIDs *WITH* data (sensu LSID spec) in cases where it makes sense to do so (e.g., image files, PDFs, perhaps DNS sequences represented as an ASCII character stream or some other specified standard binary format), and embrace LSIDs *WITHOUT* data (only metadata) -- as accomodated in the LSID spec -- for most of non-digital objects we want to exchange information about (taxon names, taxon concepts, locality descriptions, specimens, agents, bibliographic citations, etc.).
Getting back to the intended topic of this discussion (metadata persistence), I frankly am very happy that there is no requirement for metadata persistence in the LSID spec (if there was a requirement for persistence, then you might as well package it all up as data, then use the embedded versioning component of LSIDs or some other mechanism for issuing new LSIDs that are cross-linked to each other in an appropriate way).
I believe the answer to Ricardo's example is better addressed in the next discussion, concerning methods for data versioning. I think the answer to this issue (persistence of metadata) necessarily must be solved via that discussion (versioning), so maybe we should discuss the versioning issue first.
Aloha, Rich
Richard L. Pyle, PhD Database Coordinator for Natural Sciences and Associate Zoologist in Ichthyology Department of Natural Sciences, Bishop Museum 1525 Bernice St., Honolulu, HI 96817 Ph: (808)848-4115, Fax: (808)847-8252 email: deepreef@bishopmuseum.org http://hbs.bishopmuseum.org/staff/pylerichard.html
tdwg-guid mailing list tdwg-guid@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-guid