Hi Rich (et al.),I'm going to join this particular discussion in spite of the fact that I have not been able to follow the entire GUID discussion over the past couple of years and I may be repeating things that have been resolved.Let's continue to investigate whether an LSID applies to the physical specimen or the database record (or both?).What about the record(s) for that same physical object in the literature? As we mark up literature, we are going to generate LSIDs for specimen records that will need to be resolved to be related to the same physical object (in a collection) and the data record (usually in that same collection's database).Let's look at the example that Chris Lyal and I are contemplating as we work on implementing an INOTAXA pilot to show in Bratislava:1) a weevil specimen here at USNM (a type described in the BCA)2) a record for it in the museum's database (we do have a type database for insects, and it will be available in a year or two), available on the museum's website, through GBIF, and through INOTAXA3) a record from digitized and parsed BCA in INOTAXA (presumably shortly also available to GBIF in some form)4) a record for the same weevil from a paper published in the 1950s available through INOTAXA (presumably shortly also available to GBIF in some form)5) a record for that weevil from a paper published in the 1990s available through INOTAXA (presumably shortly also available to GBIF in some form)6) a published image (or series of images) in the paper from the 1990s -- but now also digitized and made available through INOTAXA (presumably shortly also available to GBIF in some form)7) a digitized image (or series of images) made in our imaging project and made available through the museum's database, INOTAXA, GBIF and MorphoBankEither 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.Or let's take that a step further and make that a fish, where not only is there a record in the museum's database with its LSID, but that same record for the same fish that was imported some years ago into FishBase (now out of date perhaps, but still available to GBIF and via Fishbase). At the time, it was imported without an LSID and FishBase has (presumably) assigned it's own LSID...Or let's say that someone else digitized their copy of the same BCA volume and followed the INOTAXA (taXMLit) and assigned yet another LSID for the specimen record...is that really the same 'record' or different from the one in #3?I would like to think that in the long run we do not need multiple LSIDs for records that refer to the same specimen or record (as long as we can be truly certain that they are 'the same'. After all, the literature markup has a whole series of unique IDs for its various parts already, so can't we refer to 'the use of LSID 123 in workID 987' or 'the use of LSID 123 on pageID 456 in workID 987'?There are a lot of IDs here, but unless every collection database already has an LSID that we can 'grab' and use in INOTAXA we are going to have to create our own LSIDs and count on a community resolver to sort it all out (and even if that were true, not all the specimens that we are going to be referring to from INOTAXA have been put in electronic form anyplace else, so we will have to assign LSIDs at least temporarily--Paul did not mention how they are going to deal with the Zoological name LSIDs as at least a temporary solution--but I assume that they have a similar problem).I'm sure I don't know what the best solution is, but that's what I'm counting on the computer scientists in this group to tell me. I just hope they tell me soon, since we're going to need answers soon!Cheers,AnnaAnna L. Weitzman, PhDBotanical and Biodiversity Informatics ResearchNational Museum of Natural HistorySmithsonian Institutionoffice: 202.633.0846mobile: 202.415.4684________________________________From: tdwg-guid-bounces@lists.tdwg.org on behalf of Richard PyleSent: Sat 02-Jun-07 5:08 AMTo: 'Paul Kirk'; 'Jason Best'; tdwg-guid@lists.tdwg.orgSubject: RE: [tdwg-guid] First step in implementing LSIDs?[Scanned]Paul and List,First, I should clarify something about my earlier post. I wrote at thestart of Scenario 3:"3) Issue data-less LSIDs without using the revision ID feature, and trackdata change history separately from the LSIDs"That should have been "...and track *metadata* change history separatelyfrom the LSIDs" (metadata, not data).So, without making things too complicated as we 'start to walk'in this domain of biodiversity informatics my vote is for avariation of scenario 3) from Rich. The reason I vote for thisis that in the fullness of time, and the 'herb.IMI' databasehas already started this, much of the metadata with beLSIDs and it's correctness (i.e. sorting out typos etc) willbe delegated to the entities who issue those LSIDs. As IPNIimproves the quality of the metadata associated with theLSIDs they issue (and if I understand correctly they do usethe scenario 3) from Rich) so the quality of the metadataassociated with a 'herb.IMI' LSID improves. The reason Iprefer the data + metadate 'model' is that in this instancethe data is fixed ... who changes collection/accessionnumbers? ... so perfect for this role. Even if a collectionmoves to a new owner the original data need not 'disappear'in the same way that DOI's move with the objects as book andjournal titles change from one publisher to another.So...if I understand correctly, you differ from my scenario 3 in that you dogenerate data-bearing LSIDs for specimens, but the data part is limited toonly the Accession number, not the complete set of data fields associatedwith the record -- correct? So, in effect, the object LSID actially appliesto is the binary accession number, not the "concept" of the specimen. I canimagine in this case that the LSID can be thought of as representing the"concept of the specimen" because the accession number itself is a surrogatefor the physical specimen. The only thing that concerns me about thisapproach is that there is a non-zero incidence of accidental duplicatecatalog numbers within a given collection, and possibly errors inassociating catalog numbers. For example, if the computer database for acollection had an error created by a technician who, for example, enteredthe metadata for accession number IMI1234569 by mistake, when it should havebeen IMI1234596 (and vice versa), then branding the accession number as"data" for the LSID means that the LSID technically *must* stay with theaccession number (not the specimen associated with the metadata for thatLSID), after the error is discovered. Not a huge problem, but couldsurprise people who had indexed the LSID before the error was discovered,who then came back to resolve it again after the error was fixed (i.e., theywould get totally wrong information). Given how rare this problem is likelyto be (against a backdrop of many far more likely problems we will have toovercome), I don't see this as a strong reason not to proceed with yourplan.Final point, the 'data' is the 'herb.IMI' accession number;in context this is a GUI because of the existence of IndexHerbariorum. So, our data will be 123456 not IMI123456because ... in the fullness of time we will include anIndex Herbariorum LSID to 'identify' the 'institutionalacronym' element of the metadata.Is the binary data for the accession number in 8-bit, or 16-bit? I'massuming 8-bit would be fine, as I suspect all collections would haveaccession numbers that can be rendered with 256-character ASCII. Is thereany "wrapper" to the number as binary data, or is it a straight ASCII binaryrepresentation (e.g.: 001100010011001000110011001101000011010100110110 for"12345")?I'm not sure I follow the logic of how embedding the accession number asdata for the LSID allows the LSID to move to a new owner. I would think theopposite. Isn't it likely that the new owner would create their ownaccession number for the specimen? In this case, they would be forced togenerate a new LSID if they were following the same practice of encoding theaccession number as "data", rather than metadata.Also, wouldn't it make more sense to include the acronym (IMI) as part ofthe data for the LSID? At least that way the "12345" would have *some*context.Finally, this approach would work only for collections where there is astrict 1:1 correlation between accession numbers and specimen objects forwhich an LSID is desired.Thanks for your comments -- this thread is already forcing me to think aboutthings in a way I hadn't thought of them before.Aloha,RichRichard L. Pyle, PhDDatabase Coordinator for Natural Sciencesand Associate Zoologist in IchthyologyDepartment of Natural Sciences, Bishop Museum1525 Bernice St., Honolulu, HI 96817Ph: (808)848-4115, Fax: (808)847-8252email: deepreef@bishopmuseum.org_______________________________________________tdwg-guid mailing list_______________________________________________tdwg-guid mailing list
************************************************************************
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.
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.
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.
CABI is an International Organization recognised by the UK Government under Statutory Instrument 1982 No. 1071.
**************************************************************************