<HTML dir=ltr><HEAD><TITLE>RE: [tdwg-guid] First step in implementing LSIDs?[Scanned]</TITLE>
<META http-equiv=Content-Type content="text/html; charset=unicode">
<META content="MSHTML 6.00.2900.3059" name=GENERATOR></HEAD>
<BODY>
<DIV id=idOWAReplyText5266 dir=ltr>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2>Jason, Rich,</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>Read these timely posts with interest as we (CABI : 'herb.IMI' and LCR NZ - Kevin Richards) are soon to implement a demonstration project for TDWG on using LSIDs in the context of biological specimens (fungi). The reason this collection was attractive (IMHO) for this demonstrator is that most of the near 400000 speciments have up to two LSIDs as part of their metadata - that for the current determination (an IndexFungorum LSID) and for the associated organism (either an IndexFungorum LSID or an IPNI LSID ... unfortunately no LSIDs yet for animals so all the fungi we have on or from animals are lacking in LSIDs in this part of the metadata).</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>So, without making things too complicated as we 'start to walk' in this domain of biodiversity informatics my vote is for a variation of scenario 3) from Rich. The reason I vote for this is that in the fullness of time, and the 'herb.IMI' database has already started this, much of the metadata with be LSIDs and it's correctness (i.e. sorting out typos etc) will be delegated to the entities who issue those LSIDs. As IPNI improves the quality of the metadata associated with the LSIDs they issue (and if I understand correctly they do use the scenario 3) from Rich) so the quality of the metadata associated with a 'herb.IMI' LSID improves. The reason I prefer the data + metadate 'model' is that in this instance the data is fixed ... who changes collection/accession numbers? ... so perfect for this role. Even if a collection moves to a new owner the original data need not 'disappear' in the same way that DOI's move with the objects as book and journal titles change from one publisher to another.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>Final point, the 'data' is the 'herb.IMI' accession number; in context this is a GUI because of the existence of Index Herbariorum. So, our data will be 123456 not IMI123456 because ... in the fullness of time we will include an Index Herbariorum LSID to 'identify' the 'institutional acronym' element of the metadata.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>Any comments on this before Kevin starts coding will be much appreciated.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>Cheers,</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>Paul</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>ps I use 'herb.IMI' in quotes because fungi are not plants, although they are traditionally considered as, and currently for their nomenclature treated as, plants.</FONT></DIV></DIV>
<DIV dir=ltr><BR>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> tdwg-guid-bounces@lists.tdwg.org on behalf of Richard Pyle<BR><B>Sent:</B> Fri 01/06/2007 23:49<BR><B>To:</B> 'Jason Best'; tdwg-guid@lists.tdwg.org<BR><B>Subject:</B> RE: [tdwg-guid] First step in implementing LSIDs?[Scanned]<BR></FONT><BR></DIV>
<DIV><BR>
<P><FONT size=2>Hi Jason,<BR><BR>Thank you for posting these questions, as I have many of the same questions<BR>for an LSID system that we plan to implement over the course of the next few<BR>months.<BR><BR>So....a quick review of the basics to make sure that my understanding is<BR>consistent with the understanding of others on this list:<BR><BR>LSIDs refer to (resolve to) "data" and "metadata". The "data" must never<BR>change for a given LSID, and is usually used for a binary digital object<BR>(like an image file, or a PDF file, for example). The "metadata" for a<BR>given LSID may change, without changing the underlying LSID. The "data"<BR>part is optional -- LSIDs containing only metadata are thought of as<BR>"conceptual" or "abstract" LSIDs -- referring to a "concept" that has no<BR>inherent digital manifestation. The "notion" of a particular image (e.g.,<BR>corresponding to the shutter release of a camera) might be represented by a<BR>"conceptual/abstract" LSID, while each digital manifestation of the captured<BR>image (RAW, JPEG, TIFF, different crops, color-corrections, etc.)<BR>could/would each have their own data-bearing LSID, where the "data" would be<BR>the binary/bit stream digital image file. The "conceptual" (data-less) LSID<BR>for the "notion" of the image could serve as a "hub", such that the metadata<BR>of each of the data-bearing LSID image files might include the conceptual<BR>LSID amongst their metadata, such that all of the digital renderings could<BR>be referred back to the same image "concept" (i.e., the same shutter-release<BR>event).<BR><BR>If I have all of the above more or less right, then I have a few questions<BR>of my own in the same context.<BR><BR>I gather from your email that you're mostly asking about LSIDs that do not<BR>(necessarily) have any digital/binary data associated with them, and you're<BR>wondering about how to manage versioning, etc. Before I address your<BR>specific questions, I want to point out that I used the word "necessarily"<BR>above -- because the first issue that I would like to understand in terms of<BR>how others approach LSIDs is the following question:<BR><BR>Does the LSID represent the *specimen*, or does it represent the *database<BR>record* for the specimen? It seems like a subtle distinction -- and it is<BR>-- but I think it's an important one. My understanding of data-less LSIDs<BR>is that they are specifically intended to represent things that have no<BR>inherent digital manifestation. In the case of a biological specimen, there<BR>is no inherent digital manifestation, so just like the notion of the<BR>"concept" of an image, the "concept" of a specimen seems an appropriate<BR>abstract object to which a data-less LSID could be assigned. In that view<BR>of the world, the database record only exists as a tool to associate the<BR>LSID with the metadata in a form that's easy to distribute electronically<BR>(i.e., as opposed to writing the LSID down with ink in a paper ledger book,<BR>and writing down associated metadata next to it).<BR><BR>I believe this is how most biologists/collection managers think about the<BR>problem, and think about how they would use LSIDs -- sort of like globally<BR>unique catalog numbers. We all have databases of specimens, and our<BR>specimens have catalog numbers, but those electronic databases and catalog<BR>numbers are not the "real" units of concern to us -- rather the physical<BR>specimens on shelves are what we're worried about. The databases are just<BR>tools to help us organize and track information about the specimens (tools<BR>that happen to have more practical value than hand-written labels physically<BR>tied to specimens -- that otherwise serve the same purpose).<BR><BR>The other perspective, which was foreign to me at first, but I'm now<BR>beginning to appreciate more, is that the LSID is *NOT* assigned to the<BR>physical specimen, but rather the electronic *database record* representing<BR>the specimen. In this case, the LSID *is* assigned to something with a<BR>digital manifestation, and therefore *can* (and *should*) be a data-bearing<BR>LSID. The data, in this case, would be the binary blob representing a<BR>concatenation of the complete database record, in some specified format.<BR>The metadata, in this case, would probably not be the data fields we think<BR>of for a specimen, but rather information about how to interpret and parse<BR>the binary data represented by the LSID, which itself would resolve to<BR>information associated with the specimen.<BR><BR>Personally, I'm still very firmly in the first camp -- that is, the<BR>assignment of "conceptual" (data-less) LSIDs to physical specimen objects,<BR>the metadata for which would be our standard specimen data fields. The LSID<BR>effectively serves as the globally unique catalog number, with the added<BR>bonus of self-resolution -- which is what, I think, the biodiversity<BR>community needs most right now. However, I'm keeping an open mind on this,<BR>so I would very much like to hear from others on this list who feel that the<BR>object represented by a specimen LSID should be the digital database record,<BR>rather than the physical specimen.<BR><BR>The reason I wrote all of the above is that I think it has direct bearing on<BR>the answers to your questions.<BR><BR>> At this stage, we are only concerned with assigning LSIDs to<BR>> collections/collection events, specimens and versions of<BR>> each. Since these aren't represented by bytecode we don't<BR>> have to be concerned about issuing a new LSID each time the<BR>> metadata changes (through improvements/changes in<BR>> determination, geolocation etc), but we also don't want to<BR>> throw away the previous revisions so the concept of a "hub"<BR>> would serve well.<BR><BR>O.K., so let's assume we will create data-less (conceptual/abstract) LSIDs<BR>for our specimens, and that the metadata are the standard specimen data<BR>fields.<BR><BR>> This hub would allow us to have a single<BR>> unchanging LSID that points to (or returns) the current<BR>> metadata but also points to each LSID for the previous<BR>> collection revisions. A change in the collection metadata<BR>> would not change the LSID of the collection hub, it would<BR>> just create a new collection version record which is issued a<BR>> new LSID and promoted to "current". This collection hub would<BR>> also point to a "hub" for each of the specimens that are<BR>> represented by the collection and these specimen hubs would<BR>> each point to the current metadata for the specimen as well<BR>> as the previous versions. We would not be using the revision<BR>> method of LSIDs, rather we would issue a totally new LSID for<BR>> each version as recommended by TDWG.<BR><BR>I'm not sure I follow -- by "collection" do you mean collecting event? Or<BR>do you mean "collection" like "Bishop Museum Fish Collection"? I read the<BR>above a couple of times, and I *think* I understand what you are saying, but<BR>I'm not sure. Let me describe my approach to the same basic problem, and see<BR>if it makes sense in the context of the above.<BR><BR>Lets suppose we generate data-less LSIDs to represent our collecting events,<BR>and data-less LSIDs to represent our specimens. In both cases, the LSIDs<BR>represent the abstract notion of the collecting event or specimen; not the<BR>electronic database record per se. Our metadata for each LSID would<BR>correspond to our usual data fields for each kind of object (i.e., date,<BR>collector, etc. for collecting events; and preservation method,<BR>determinations, etc. for specimens).<BR><BR>The question, it seems (at least the question I have, and I think the<BR>question you have) is how do we manage edit histories of metadata elements.<BR>I can think of three scenarios to deal with this:<BR><BR>1) Assign the LSID to the database record object, not the conceptual<BR>collecting event/specimen.<BR>In this scenario, the LSID would represent the database record itself, and<BR>would have data. The data would be a binary concatenation of all the<BR>elements of a typical specimen data record, with some sort of delimiter<BR>between elements (fields). This binary digital object would be fixed and<BR>permanent, and would never change. Metadata associated with each of these<BR>LSIDs would include information on how to parse the binary data blob into<BR>its component fields/elements, so they could be rendered, searched, etc. If<BR>some data element needed to change (e.g., the collector's name was<BR>originally misspelled), then a replacement LSID would be generated for the<BR>new binary concatenated data blob, and this new LSID would use the<BR>versioning feature of LSIDs (i.e., it would differ from the original LSID<BR>only in the revision id part of the LSID. Thus, every data edit would be<BR>automatically issued a new LSID, because the data component itself has<BR>changed. As I stated above, I'm not too keen on this approach, based on my<BR>current understanding.<BR><BR>2) Utilize the Revision ID part of an LSID to track the history of metadata<BR>changes<BR>In this scenario, the LSIDs would themselves be data-less, and the metadata<BR>would be our typical data fields. If any of our data fields changed, we<BR>would issue a LSID differing from the original only by the Revision ID<BR>component. This way, each version of the data gets its own LSID, and<BR>resolving any one of the versions automatically redirects to the latest/most<BR>recent version, using the LSID versioning features. This way, if you strip<BR>the revision ID part of the LSID, you're essentially left with an LSID that<BR>applies to the "concept" of the specimen (i.e., the "hub" LSID). This seems<BR>almost the same method you described above (if I understood you correctly),<BR>except that the new LSIDs are generated by altering only the Revision ID<BR>part of the LSID, rather than creating a new LSID with a different Object<BR>ID. I'm not sure why you would want to issue new LSIDs with new Object ID<BR>components for what effectively represent different versions of metadata for<BR>the same object. The main problem I have with this approach is that I don't<BR>think this is what was intended by the LSID revision ID component. I<BR>believe the revision ID was intended as a mechanism to allow altering the<BR>*data*, not to track changes to the metadata. In other words, I think it<BR>goes against the spirit of the intent of LSIDs to use the revision ID (or<BR>issue new LSIDs with different Object Ids) to track changing metadata. But<BR>I may well be wrong about this.<BR><BR>3) Issue data-less LSIDs without using the revision ID feature, and track<BR>data change history separately from the LSIDs<BR>In this scenario, the LSIDs are *not* used as a tool to track versioning of<BR>metadata. Rather, they are issued to the "concept" of an object (e.g.,<BR>collecting event or specimen), with no inherent binary "data", and the<BR>metadata resolved for the LSID would be a function of whatever resolve<BR>service is used. Tracking historical changes to the metadata would be the<BR>responsibility of the data issuer, but would not involve the generation of<BR>new LSIDs. Indeed, there's nothing stopping the resolver service from<BR>maintaining a complete log of metadata changes as part of the metadata<BR>associated with the LSID.<BR><BR>I personally favor the third approach, because only a small fraction of<BR>people are concerned with metadata edit history. I say this in the context<BR>that multiple historical determinations are *not*, in my mind, examples of<BR>metadata edit history. To me, a determination is an object in its own<BR>right, perhaps worthy of its own LSID. Part of the metadata of a specimen<BR>could be selecting from among multiple determinations which is deemed to be<BR>correct/current from the perspective of the specimen owner (=museum<BR>collection). But when I think of metadata edits and versioning, I think of<BR>correcting typos and otherwise fixing mistakes -- not the act of linking new<BR>information to an existing LSID (as a determination would be).<BR><BR>I'm not sure if any of this addresses your questions, but I think these<BR>issues are all inter-related. I would very-much like to hear from others on<BR>this stuff.<BR><BR>Aloha,<BR>Rich<BR><BR>Richard L. Pyle, PhD<BR>Database Coordinator for Natural Sciences<BR> and Associate Zoologist in Ichthyology<BR>Department of Natural Sciences, Bishop Museum<BR>1525 Bernice St., Honolulu, HI 96817<BR>Ph: (808)848-4115, Fax: (808)847-8252<BR>email: deepreef@bishopmuseum.org<BR><A href="http://hbs.bishopmuseum.org/staff/pylerichard.html">http://hbs.bishopmuseum.org/staff/pylerichard.html</A><BR><BR><BR><BR>_______________________________________________<BR>tdwg-guid mailing list<BR>tdwg-guid@lists.tdwg.org<BR><A href="http://lists.tdwg.org/mailman/listinfo/tdwg-guid">http://lists.tdwg.org/mailman/listinfo/tdwg-guid</A><BR></FONT></P></DIV><p><font face="Arial" size="1">************************************************************************<br>
The information contained in this e-mail and any files transmitted with it is confidential and is for the exclusive use of the intended recipient. If you are not the intended recipient please note that any distribution, copying or use of this communication or the information in it is prohibited. <br>
<br>
Whilst CAB International trading as CABI takes steps to prevent the transmission of viruses via e-mail, we cannot guarantee that any e-mail or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions.<br>
<br>
If you have received this communication in error, please notify us by e-mail at cabi@cabi.org or by telephone on +44 (0)1491 829199 and then delete the e-mail and any copies of it.<br>
<br>
CABI is an International Organization recognised by the UK Government under Statutory Instrument 1982 No. 1071.<br>
<br>
**************************************************************************</font><br>
</p>
</BODY></HTML>