June 2007 - tdwg-tag - lists.tdwg.org

RE: [tdwg-guid] First step in implementing LSIDs
by Kevin Richards 09 Jun '07

09 Jun '07

I agree with Jason. It is not the GUID that is the cause of all the problems here - THERE IS NOTHING WRONG WITH LSIDS - we just need to move on and start using them in our own context (or any other suitable GUID - LSIDs are only the recommended GUID, NOT the only premissable GUID). If it all falls to pieces later on we could just do a search and replace to change all our GUIDs to some other scheme (to quote Bob, just serious). I agree, it is the RDF/metadata/ontologies that are the key to getting things working well. Kevin >>> "Jason Best" <jbest(a)brit.org> 06/06/07 8:39 AM >>> Rod, I've only had a chance to quickly skim the documents you reference, but it seems to me that the alternatives to LSIDs don't necessarily make the issues with which we are wrestling go away. We still need to decide WHAT a URI references - is it the metadata, the physical object etc? URIs don't explicitly require persistance, while LSIDs do so I see that as a positive for adopting a standard GUID that is explicit in that regard. I think the TDWG effort to spec an HTTP proxy for LSIDs makes it clear that the technical hurdles of implementing an LSID resolver (SVR records, new protocol, client limitations etc) are a bit cumbersome, but I don't think the underlying concept is fatally flawed. In reading these discussions, I'm starting to believe/understand that RDF may hold the key, regardless of the GUID that is implemented. Now I have to go read up more on RDF to see if my new-found belief has merit! ;) Jason ________________________________ From: Roderic Page [mailto:r.page@bio.gla.ac.uk] Sent: Tuesday, June 05, 2007 2:10 PM To: Chuck Miller Cc: Bob Morris; Kevin Richards; tdwg-guid(a)lists.tdwg.org; WEITZMAN(a)si.edu; Jason Best Subject: Re: [tdwg-guid] First step in implementing LSIDs?[Scanned] Maybe it's time to bite the bullet and consider the elephant in the room -- LSIDs might not be what we want. Markus Döring sent some nice references to the list in April, which I've repeated below, there is also http://dx.doi.org/10.1109/MIS.2006.62 . I think the LSID debate is throwing up issues which have been addressed elsewhere (e.g., identifiers for physical things versus digital records), and some would argue have been solved to at least some people's satisfaction. LSIDs got us thinking about RDF, which is great. But otherwise I think they are making things more complicated than they need to be. I think this community is running a grave risk of committing to a technology that nobody else takes that seriously (hell, even the http://lsid.sourceforge.net/ web site is broken). The references posted by Markus Döring were: (1) http://www.dfki.uni-kl.de/dfkidok/publications/TM/07/01/tm-07-01.pdf "Cool URIs for the Semantic Web" by Leo Sauermann DFKI GmbH, Richard Cyganiak Freie Universität Berlin (D2R author), Max Völkel FZI Karlsruhe The authors of this document come from the semantic web community and discuss what kind of URIs should be used for RDF resources. (2) http://www.w3.org/2001/tag/doc/URNsAndRegistries-50 This one here is written by the W3C and addresses the questions "When should URNs or URIs with novel URI schemes be used to name information resources for the Web?" The answers given are "Rarely if ever" and "Probably not". Common arguments in favor of such novel naming schemas are examined, and their properties compared with those of the existing http: URI scheme. Regards Rod ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ WARNING: This email and any attachments may be confidential and/or privileged. They are intended for the addressee only and are not to be read, used, copied or disseminated by anyone receiving them in error. If you are not the intended recipient, please notify the sender by return email and delete this message and any attachments. The views expressed in this email are those of the sender and do not necessarily reflect the official views of Landcare Research. Landcare Research http://www.landcareresearch.co.nz ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

12 25

Re: [tdwg-guid] First step in implementing LSIDs
by Donat Agosti 07 Jun '07

07 Jun '07

Dear colleagues and Jonathan Below a email from Jonathan Rees at the Science Commons, an institution with a great interest and experience in identifiers. Since systematics ought be lnked to the greated science, it seems all to obvious to get SC involved. It would be interesting to get something like their Neurocommons up and running to show the potential of having all these identifiers and other standards in place (http://sciencecommons.org/projects/data/) Obivously, there is on interest in bioinformatics, and it might also be a way to sync other with other large projects like EOL. Furthermore, I would also like to point out to the forthcoming OASIS (http://www.oasis-open.org/home/index.php) / Creative Commons meeting (http://conservationcommons.org/)(June 26,.Arlington), where the conservationists talk to OASIS to develop standards allowing exchanging of conservation information, and I hope also linking our taxonomic data with their work. Contact for that is Silvio Olivieri and Tom Hammond, and Lee Belbin is involved. Donat -----Original Message----- From: Jonathan Rees [mailto:jar@creativecommons.org] Sent: Wednesday, June 06, 2007 8:32 PM To: Donat Agosti Cc: John Wilbanks Subject: Re: [Fwd: LSID discussion - a practical suggestion?] Donat, John Wilbanks forwarded your email to me. I spent a while recently trying to understand LSID's. I concluded that they don't work very well, and that their shortcomings help explain why they've become pretty much obsolete. The W3C web architecture recommendations are a much better way to go. A lot of the identifier-angst in the thread that John forwarded is resolved if you buy the semantic web religion: each identifier (URI) denotes something; you have to say somehow what that thing is; and puns are not allowed. So the metadata record, if it has an identifier at all (and it probably should, for provenance purposes), gets a different identifier from the data that it describes, etc. Regarding identifiers, please check out: http://sw.neurocommons.org/2007/uri-explanation.html http://wiki.neurocommons.org/CommonNaming http://www.dfki.uni-kl.de/~sauermann/2006/11/cooluris/ http://sw.neurocommons.org/2007/kb.html I will be reporting to the W3C Semantic Web Health Care and Life Sciences interest group next week on this subject. Would be happy to talk with you as much as you like about it. I'm planning to attempt contact with Jim Hendler, who I understand is a technical advisor to EOL, to see whether I can offer to help with EOL architecture as it relates to the semantic web. What these days is called "biodiversity informatics" is squarely in Science Commons's domain of interest and I would be delighted to get connected with groups discussing it. Best Jonathan Rees

1 0

Re: [tdwg-guid] First step in implementing LSIDs?[Scanned]
by Kevin Richards 06 Jun '07

06 Jun '07

I agree with Roger that LSIDs should identify the data record, not the physical object. In many cases there will not be a physical object, event or whatever. Any physical object is only really "described" by the digital record (and this does not even guarantee the connection is correct - due to typos etc). Also consider the situation where you have a single specimen and two different databases that have data about that specimen - should they use the same LSID? I think not. For one, when you "resolve" the LSID it will only ever fetch the data for the database that is the "owner" of the LSID, and is therefore handling the resolution. It would be better, I think, to use metadata of the objects to connect these two datasets - eg the sameAs, replacedBy, etc RDF tags that others have mentioned on this thread. Of course it is crucial that we reuse LSIDs where possible, but only if when referring to an external ID (ie not much point in having the ID for "your" data being the LSID of another system - then your data will never be uniquely identified, or retrievable). Does this make sense? Kevin >>> Roger Hyam <roger(a)tdwg.org> 06/04/07 9:31 PM >>> Wow this is a big thread appears over the weekend! I am posting without having time to read and digest everything in its entirety but only to answer Jason's original question I hope. Received wisdom is don't use the version part of an LSID. If you did you would be creating new LSIDs anyhow so in a way it doesn't matter. The identifier is supposed to be opaque so the client should never break the LSID into parts anyhow and would only to byte identical comparisons to the LSIDs themselves to see whether they are the same things or not. If you want to do versioning create an LSID for the "thing that changes" and an LSID for each version of that thing. Each of the versions are linked by dcterm:replaces and dcterm:isReplacedBy. http://purl.org/dc/terms/isReplacedBy http://purl.org/dc/terms/replaces Each version points to the LSID for the "thing that changes" with dcterm:isVersionOf http://purl.org/dc/terms/isVersionOf We have our own vocabulary item for the one link in the change that isn't support by Dublin Core. tcom:versionedAs http://rs.tdwg.org/ontology/voc/Common#versionedAs This points from the "thing that changes" to the current version. i.e. the version that has identical metadata to itself. Anyone who caches the data for the current version of the LSID can know which version they have so if it becomes retrospectively important to get back to the actual version it is possible. Philosophically when do you version? Only the provider can say that a change is significant enough to warrant a new version - but if you have gone to the trouble of implementing version control you may as well do it for any change. Only the data provider can say whether the "thing that changes" has changed so much that it is no longer the same thing. Personally I believe this approach nails the versioning issues. There is the perennial debate about whether an LSID points to a physical object or not (when it doesn't have byte stream associated with it). The answer is easy. It points to a digital object. If you doubt this try destroying a physical specimen and then asking whether you should do away with the LSID and associated data? Clearly you would maintain a record of something you once had so that you could still return the data. Likewise if you gave the specimen to another institution you would maintain a record of having had it but would, hopefully, link to the new institutions record of it. Hope this is helpful. Roger On 3 Jun 2007, at 15:08, Paul Kirk wrote: > Anybody got any views (strong, otherwise or proxy for others views) > on whether the LSID should refer to data+metadata or just metadata? > > From where I sit, closer to physical objects than bits in a bit > stream, I favour the former. Take names for example. Strings of > characters and spaces whose form is governed by Codes and one of > the means, if not the primary mean, by which we communicate > (verbally, in print or electronically) about biodiversity. For > LSIDs applied to names my understanding is that they must resolve > to an unchanging bit stream representing the name (we implemented > this in Index Fungorum 1st May 2005 when we set up the demo > resolver) but the associated metadata may change. If I'm correct on > this one how does it work for LSIDs only resolving metadata, which > is not fixed. I know Roger tried to explain this one to me but I'm > still not sure it's entirely logical. > > I think I'm with Rod on the LSIDs for specimens - they do not > represent the physical object but are a sort of digital substitute > (or substitutes) of that object. > > And I also support Rods view that we should as far as possible > avoid the duplication of GUIDs. Thus, for names it appears logical > (although I must declare an 'interest' here so others may see a > conflict) that the globally recognized nomenclators (IPNI, IF, > ZooBank (soon), the bacterial list, the algal list, the virus > database - I forget the acronyms here) be charged with providing > these GUIDs (currently as LSIDs) for all of us to use. And > following on from that, the 'institution' which is charged with > providing the digital representation of specimens is the > institution which is the custodian of the physical object. > > Regards, > > Paul > > From: Roderic Page [mailto:r.page@bio.gla.ac.uk] > Sent: Sun 03/06/2007 12:03 > To: Weitzman, Anna > Cc: Richard Pyle; Paul Kirk; Jason Best; tdwg-guid(a)lists.tdwg.org > Subject: Re: [tdwg-guid] First step in implementing LSIDs?[Scanned] > > I think we need to be clear what gets an LSID (or a GUID in general). > > Some of the things listed by Anna are digital records, such as an > image. It seems simplest to give these GUIDs that identify the > image, with metadata linking the image to the thing the image > depicts (there are existing RDF vocabularies to do this). > > Some things listed, such as a specimen, are physical objects. These > are different from digital objects, and they way in which GUIDs > that identify real things are handled has caused all manner of > discussion (see http://www.w3.org/DesignIssues/HTTP-URI and > related pages bookmarked at http://del.icio.us/rdmpage/303). LSIDs > don't handle this well, unless we rely on metadata saying "the > thing identified by." > > So, at least on this level to say that all seven things get the > same GUID is clearly a non starter. > > Relationships between things can be easily specified in metadata > ("is part of", "depicts", "is kind of"). > > The final issue is GUID reuse, that is, if somebody uses a INOTAXA > record, they should at a minimum refer to the INOTAXA LSID. This > would particularly apply to aggregators such as GBIF, who should > not present their own identifiers unless GBIF has actually created > the data. You often state "presumably shortly also available to > GBIF in some form". It's not clear to what that means, but if it's > GBIF because INOTAXA serves it, then I think GBIF should use > INOTAXA LSIDs to refer to INOTAXA records. > > Clearly, generating a plethora a new, effectively local ids > (masquerading as global) is not a recipe for progress. If we don't > reuse GUIDs we are wasting our time. > > Regards > > Rod > > > > > > On 2 Jun 2007, at 18:53, Weitzman, Anna wrote: > >> 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 INOTAXA >> 3) 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 MorphoBank >> >> 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. >> >> 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, >> 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(a)si.edu >> >> ________________________________ >> >> From: tdwg-guid-bounces(a)lists.tdwg.org on behalf of Richard Pyle >> Sent: Sat 02-Jun-07 5:08 AM >> To: 'Paul Kirk'; 'Jason Best'; tdwg-guid(a)lists.tdwg.org >> Subject: RE: [tdwg-guid] First step in implementing LSIDs?[Scanned] >> >> >> >> >> Paul and List, >> >> First, I should clarify something about my earlier post. I wrote >> at the >> start of Scenario 3: >> >> "3) Issue data-less LSIDs without using the revision ID feature, >> and track >> data change history separately from the LSIDs" >> >> That should have been "...and track *metadata* change history >> separately >> from 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 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. >> >> So...if I understand correctly, you differ from my scenario 3 in >> that you do >> generate data-bearing LSIDs for specimens, but the data part is >> limited to >> only the Accession number, not the complete set of data fields >> associated >> with the record -- correct? So, in effect, the object LSID >> actially applies >> to is the binary accession number, not the "concept" of the >> specimen. I can >> imagine in this case that the LSID can be thought of as >> representing the >> "concept of the specimen" because the accession number itself is a >> surrogate >> for the physical specimen. The only thing that concerns me about >> this >> approach is that there is a non-zero incidence of accidental >> duplicate >> catalog numbers within a given collection, and possibly errors in >> associating catalog numbers. For example, if the computer >> database for a >> collection had an error created by a technician who, for example, >> entered >> the metadata for accession number IMI1234569 by mistake, when it >> should have >> been IMI1234596 (and vice versa), then branding the accession >> number as >> "data" for the LSID means that the LSID technically *must* stay >> with the >> accession number (not the specimen associated with the metadata >> for that >> LSID), after the error is discovered. Not a huge problem, but could >> surprise 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., they >> would get totally wrong information). Given how rare this problem >> is likely >> to be (against a backdrop of many far more likely problems we will >> have to >> overcome), I don't see this as a strong reason not to proceed with >> your >> plan. >> >>> 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. >> >> Is the binary data for the accession number in 8-bit, or 16-bit? I'm >> assuming 8-bit would be fine, as I suspect all collections would have >> accession numbers that can be rendered with 256-character ASCII. >> Is there >> any "wrapper" to the number as binary data, or is it a straight >> ASCII binary >> representation (e.g.: >> 001100010011001000110011001101000011010100110110 for >> "12345")? >> >> I'm not sure I follow the logic of how embedding the accession >> number as >> data for the LSID allows the LSID to move to a new owner. I would >> think the >> opposite. Isn't it likely that the new owner would create their own >> accession number for the specimen? In this case, they would be >> forced to >> generate a new LSID if they were following the same practice of >> encoding the >> accession number as "data", rather than metadata. >> >> Also, wouldn't it make more sense to include the acronym (IMI) as >> part of >> the 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 a >> strict 1:1 correlation between accession numbers and specimen >> objects for >> which an LSID is desired. >> >> Thanks for your comments -- this thread is already forcing me to >> think about >> things in a way I hadn't thought of them before. >> >> 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(a)bishopmuseum.org >> http://hbs.bishopmuseum.org/staff/pylerichard.html >> >> >> >> _______________________________________________ >> tdwg-guid mailing list >> tdwg-guid(a)lists.tdwg.org >> http://lists.tdwg.org/mailman/listinfo/tdwg-guid >> >> >> _______________________________________________ >> tdwg-guid mailing list >> tdwg-guid(a)lists.tdwg.org >> http://lists.tdwg.org/mailman/listinfo/tdwg-guid >> > > ---------------------------------------- > Professor Roderic D. M. Page > Editor, Systematic Biology > DEEB, IBLS > Graham Kerr Building > University of Glasgow > Glasgow G12 8QP > United Kingdom > > Phone: +44 141 330 4778 > Fax: +44 141 330 2792 > email: r.page(a)bio.gla.ac.uk > web: http://taxonomy.zoology.gla.ac.uk/rod/rod.html > iChat: aim://rodpage1962 > reprints: http://taxonomy.zoology.gla.ac.uk/rod/pubs.html > > Subscribe to Systematic Biology through the Society of Systematic > Biologists Website: http://systematicbiology.org > Search for taxon names: http://darwin.zoology.gla.ac.uk/~rpage/portal/ > Find out what we know about a species: http://ispecies.org > Rod's rants on phyloinformatics: http://iphylo.blogspot.com > Rod's rants on ants: http://semant.blogspot.com > > > > ********************************************************************** > ** > 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(a)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. > > ********************************************************************** > **** > > _______________________________________________ > tdwg-guid mailing list > tdwg-guid(a)lists.tdwg.org > http://lists.tdwg.org/mailman/listinfo/tdwg-guid ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ WARNING: This email and any attachments may be confidential and/or privileged. They are intended for the addressee only and are not to be read, used, copied or disseminated by anyone receiving them in error. If you are not the intended recipient, please notify the sender by return email and delete this message and any attachments. The views expressed in this email are those of the sender and do not necessarily reflect the official views of Landcare Research. Landcare Research http://www.landcareresearch.co.nz ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

6 6

RE: [tdwg-guid] First step in implementing LSIDs?[Scanned]
by Kevin Richards 05 Jun '07

05 Jun '07

No. The "fuzziness" only comes from the fact that everyone has a different viewpoint and understanding of what an LSID (or any GUID) IS or what it DOES. The idea of GUIDs is very simple - a globally unique ID for some information sitting on the web somewhere. The confusion comes in when people apply this idea differently depending on their job/background/role etc. Ie myself having a software development background, I tend to look at things from a data/database/software point of view, whereas a systematist is far more interested in the physical objects the IDs refer to and how to apply this to their work - both are very important but the overall outcome should be the same. LSIDs are just GUIDs that may be used to identify digital objects, probably using the TDWG RDF ontologies, that may or may not refer to/describe a physical object. It may be the ontologies and the way we interpret these ontologies that confuses people, not the GUID itself. So it is the ontologies that need "voting on".. Kevin >>> "Chuck Miller" <Chuck.Miller(a)mobot.org> 06/06/07 6:40 AM >>> I just want to take the time here to say AAAAAARGGGGGH!!! Does anyone else share this with me? It is clear as day that we do not have a decision on what an LSID specifically and exactly is (for this community), much less how to actually make use of an LSID, and then how in world could we reliably relate them together. It's difficult to accept that so much time has been spent by so many people discussing this at length in meetings and workshops, in Wikis, and in emails but still we have different opinions of what an LSID specifically is for biodiversity data. What mechanism can we employ that will end this LSID fuzziness once and for all, so we can move on to making them functional? Is the official, unambiguous definition of an LSID something that needs to be voted on and accepted at the TDWG meeting? Perhaps several definitions, one for each type of LSID - concept, name, specimen, literature, and so on? But a definition (right or wrong in some folks' opinion) that will end the debate. Chuck Chuck Miller VP-IT & CIO Missouri Botanical Garden St. Louis, MO, USA -----Original Message----- From: tdwg-guid-bounces(a)lists.tdwg.org [mailto:tdwg-guid-bounces@lists.tdwg.org] On Behalf Of Bob Morris Sent: Tuesday, June 05, 2007 12:15 AM To: Kevin Richards Cc: tdwg-guid(a)lists.tdwg.org; WEITZMAN(a)si.edu; jbest(a)brit.org Subject: Re: [tdwg-guid] First step in implementing LSIDs?[Scanned] I am constantly confused in this thread by the term "use an LSID" seeming to mean "have an LSID". Whenever there is a "conceptual" object such as a physical object or an observation, there is a strong tradition that its LSID have empty data and meaningful metadata. In these cases, I strongly hope there will be such an LSID and that there be only a single one for it, which is not actually required by the LSID spec. Without this, for example, an assertion that two different LSID1 and LSID2 both identify the type specimen for Aus bus depends on good will and accurate data. On the other hand, if I am presented with two LSIDs that are identical, no reasoning on returned metadata, nor even resolution, is required to know that they are talking about the same thing. Thus, if two different specimen records, intending to describe the same thing, refer to the same LSID in their data in some attribute like "DESCRIBES", then those records are unambiguously describing the same thing. On the other hand, if the specimen records \themselves/ are to have LSIDs, they must NOT have the same LSID, as that violates the specification and purpose of LSID (or any other GUID). I think the confusion here may be some notion that an LSID inherently describes something. It doesn't. It only serves to distinguish its target from other things that may have LSIDs. Nothing in the LSID spec implies that the metadata returned by LSID resolution is a description, though some communities may wish to do make it so. For mutable electronic objects, such as a specimen record given an LSIDs, it would be entirely reasonable for the resolution to return the current content of the record as its LSID metadata. It would be incorrect to return that record as data, if the content of that record is ever permitted to change (which specimen records usually are). On 6/5/07, Kevin Richards <richardsk(a)landcareresearch.co.nz> wrote: > I agree with Roger that LSIDs should identify the data record, not the > physical object. In many cases there will not be a physical object, > event or whatever. Any physical object is only really "described" by > the digital record (and this does not even guarantee the connection is > correct - due to typos etc). > > Also consider the situation where you have a single specimen and two > different databases that have data about that specimen - should they use > the same LSID? I think not. For one, when you "resolve" the LSID it > will only ever fetch the data for the database that is the "owner" of > the LSID, and is therefore handling the resolution. It would be better, > I think, to use metadata of the objects to connect these two datasets - > eg the sameAs, replacedBy, etc RDF tags that others have mentioned on > this thread. Of course it is crucial that we reuse LSIDs where > possible, but only if when referring to an external ID (ie not much > point in having the ID for "your" data being the LSID of another system > - then your data will never be uniquely identified, or retrievable). > Does this make sense? > > Kevin > > > >>> Roger Hyam <roger(a)tdwg.org> 06/04/07 9:31 PM >>> > Wow this is a big thread appears over the weekend! > > I am posting without having time to read and digest everything in its > entirety but only to answer Jason's original question I hope. > > Received wisdom is don't use the version part of an LSID. If you did > you would be creating new LSIDs anyhow so in a way it doesn't matter. > The identifier is supposed to be opaque so the client should never > break the LSID into parts anyhow and would only to byte identical > comparisons to the LSIDs themselves to see whether they are the same > things or not. > > If you want to do versioning create an LSID for the "thing that > changes" and an LSID for each version of that thing. > > Each of the versions are linked by dcterm:replaces and > dcterm:isReplacedBy. > > http://purl.org/dc/terms/isReplacedBy > > http://purl.org/dc/terms/replaces > > Each version points to the LSID for the "thing that changes" with > dcterm:isVersionOf > > http://purl.org/dc/terms/isVersionOf > > We have our own vocabulary item for the one link in the change that > isn't support by Dublin Core. tcom:versionedAs > > http://rs.tdwg.org/ontology/voc/Common#versionedAs > > This points from the "thing that changes" to the current version. > i.e. the version that has identical metadata to itself. Anyone who > caches the data for the current version of the LSID can know which > version they have so if it becomes retrospectively important to get > back to the actual version it is possible. > > Philosophically when do you version? Only the provider can say that a > change is significant enough to warrant a new version - but if you > have gone to the trouble of implementing version control you may as > well do it for any change. Only the data provider can say whether the > "thing that changes" has changed so much that it is no longer the > same thing. > > Personally I believe this approach nails the versioning issues. > > There is the perennial debate about whether an LSID points to a > physical object or not (when it doesn't have byte stream associated > with it). The answer is easy. It points to a digital object. If you > doubt this try destroying a physical specimen and then asking whether > you should do away with the LSID and associated data? Clearly you > would maintain a record of something you once had so that you could > still return the data. Likewise if you gave the specimen to another > institution you would maintain a record of having had it but would, > hopefully, link to the new institutions record of it. > > Hope this is helpful. > > Roger > > > > On 3 Jun 2007, at 15:08, Paul Kirk wrote: > > > Anybody got any views (strong, otherwise or proxy for others views) > > on whether the LSID should refer to data+metadata or just metadata? > > > > From where I sit, closer to physical objects than bits in a bit > > stream, I favour the former. Take names for example. Strings of > > characters and spaces whose form is governed by Codes and one of > > the means, if not the primary mean, by which we communicate > > (verbally, in print or electronically) about biodiversity. For > > LSIDs applied to names my understanding is that they must resolve > > to an unchanging bit stream representing the name (we implemented > > this in Index Fungorum 1st May 2005 when we set up the demo > > resolver) but the associated metadata may change. If I'm correct on > > this one how does it work for LSIDs only resolving metadata, which > > is not fixed. I know Roger tried to explain this one to me but I'm > > still not sure it's entirely logical. > > > > I think I'm with Rod on the LSIDs for specimens - they do not > > represent the physical object but are a sort of digital substitute > > (or substitutes) of that object. > > > > And I also support Rods view that we should as far as possible > > avoid the duplication of GUIDs. Thus, for names it appears logical > > (although I must declare an 'interest' here so others may see a > > conflict) that the globally recognized nomenclators (IPNI, IF, > > ZooBank (soon), the bacterial list, the algal list, the virus > > database - I forget the acronyms here) be charged with providing > > these GUIDs (currently as LSIDs) for all of us to use. And > > following on from that, the 'institution' which is charged with > > providing the digital representation of specimens is the > > institution which is the custodian of the physical object. > > > > Regards, > > > > Paul > > > > From: Roderic Page [mailto:r.page@bio.gla.ac.uk] > > Sent: Sun 03/06/2007 12:03 > > To: Weitzman, Anna > > Cc: Richard Pyle; Paul Kirk; Jason Best; tdwg-guid(a)lists.tdwg.org > > Subject: Re: [tdwg-guid] First step in implementing LSIDs?[Scanned] > > > > I think we need to be clear what gets an LSID (or a GUID in general). > > > > Some of the things listed by Anna are digital records, such as an > > image. It seems simplest to give these GUIDs that identify the > > image, with metadata linking the image to the thing the image > > depicts (there are existing RDF vocabularies to do this). > > > > Some things listed, such as a specimen, are physical objects. These > > are different from digital objects, and they way in which GUIDs > > that identify real things are handled has caused all manner of > > discussion (see http://www.w3.org/DesignIssues/HTTP-URI and > > related pages bookmarked at http://del.icio.us/rdmpage/303). LSIDs > > don't handle this well, unless we rely on metadata saying "the > > thing identified by." > > > > So, at least on this level to say that all seven things get the > > same GUID is clearly a non starter. > > > > Relationships between things can be easily specified in metadata > > ("is part of", "depicts", "is kind of"). > > > > The final issue is GUID reuse, that is, if somebody uses a INOTAXA > > record, they should at a minimum refer to the INOTAXA LSID. This > > would particularly apply to aggregators such as GBIF, who should > > not present their own identifiers unless GBIF has actually created > > the data. You often state "presumably shortly also available to > > GBIF in some form". It's not clear to what that means, but if it's > > GBIF because INOTAXA serves it, then I think GBIF should use > > INOTAXA LSIDs to refer to INOTAXA records. > > > > Clearly, generating a plethora a new, effectively local ids > > (masquerading as global) is not a recipe for progress. If we don't > > reuse GUIDs we are wasting our time. > > > > Regards > > > > Rod > > > > > > > > > > > > On 2 Jun 2007, at 18:53, Weitzman, Anna wrote: > > > >> 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 INOTAXA > >> 3) 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 MorphoBank > >> > >> 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. > >> > >> 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, > >> 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(a)si.edu > >> > >> ________________________________ > >> > >> From: tdwg-guid-bounces(a)lists.tdwg.org on behalf of Richard Pyle > >> Sent: Sat 02-Jun-07 5:08 AM > >> To: 'Paul Kirk'; 'Jason Best'; tdwg-guid(a)lists.tdwg.org > >> Subject: RE: [tdwg-guid] First step in implementing LSIDs?[Scanned] > >> > >> > >> > >> > >> Paul and List, > >> > >> First, I should clarify something about my earlier post. I wrote > >> at the > >> start of Scenario 3: > >> > >> "3) Issue data-less LSIDs without using the revision ID feature, > >> and track > >> data change history separately from the LSIDs" > >> > >> That should have been "...and track *metadata* change history > >> separately > >> from 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 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. > >> > >> So...if I understand correctly, you differ from my scenario 3 in > >> that you do > >> generate data-bearing LSIDs for specimens, but the data part is > >> limited to > >> only the Accession number, not the complete set of data fields > >> associated > >> with the record -- correct? So, in effect, the object LSID > >> actially applies > >> to is the binary accession number, not the "concept" of the > >> specimen. I can > >> imagine in this case that the LSID can be thought of as > >> representing the > >> "concept of the specimen" because the accession number itself is a > >> surrogate > >> for the physical specimen. The only thing that concerns me about > >> this > >> approach is that there is a non-zero incidence of accidental > >> duplicate > >> catalog numbers within a given collection, and possibly errors in > >> associating catalog numbers. For example, if the computer > >> database for a > >> collection had an error created by a technician who, for example, > >> entered > >> the metadata for accession number IMI1234569 by mistake, when it > >> should have > >> been IMI1234596 (and vice versa), then branding the accession > >> number as > >> "data" for the LSID means that the LSID technically *must* stay > >> with the > >> accession number (not the specimen associated with the metadata > >> for that > >> LSID), after the error is discovered. Not a huge problem, but could > >> surprise 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., they > >> would get totally wrong information). Given how rare this problem > >> is likely > >> to be (against a backdrop of many far more likely problems we will > >> have to > >> overcome), I don't see this as a strong reason not to proceed with > >> your > >> plan. > >> > >>> 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. > >> > >> Is the binary data for the accession number in 8-bit, or 16-bit? I'm > >> assuming 8-bit would be fine, as I suspect all collections would have > >> accession numbers that can be rendered with 256-character ASCII. > >> Is there > >> any "wrapper" to the number as binary data, or is it a straight > >> ASCII binary > >> representation (e.g.: > >> 001100010011001000110011001101000011010100110110 for > >> "12345")? > >> > >> I'm not sure I follow the logic of how embedding the accession > >> number as > >> data for the LSID allows the LSID to move to a new owner. I would > >> think the > >> opposite. Isn't it likely that the new owner would create their own > >> accession number for the specimen? In this case, they would be > >> forced to > >> generate a new LSID if they were following the same practice of > >> encoding the > >> accession number as "data", rather than metadata. > >> > >> Also, wouldn't it make more sense to include the acronym (IMI) as > >> part of > >> the 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 a > >> strict 1:1 correlation between accession numbers and specimen > >> objects for > >> which an LSID is desired. > >> > >> Thanks for your comments -- this thread is already forcing me to > >> think about > >> things in a way I hadn't thought of them before. > >> > >> 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(a)bishopmuseum.org > >> http://hbs.bishopmuseum.org/staff/pylerichard.html > >> > >> > >> > >> _______________________________________________ > >> tdwg-guid mailing list > >> tdwg-guid(a)lists.tdwg.org > >> http://lists.tdwg.org/mailman/listinfo/tdwg-guid > >> > >> > >> _______________________________________________ > >> tdwg-guid mailing list > >> tdwg-guid(a)lists.tdwg.org > >> http://lists.tdwg.org/mailman/listinfo/tdwg-guid > >> > > > > ---------------------------------------- > > Professor Roderic D. M. Page > > Editor, Systematic Biology > > DEEB, IBLS > > Graham Kerr Building > > University of Glasgow > > Glasgow G12 8QP > > United Kingdom > > > > Phone: +44 141 330 4778 > > Fax: +44 141 330 2792 > > email: r.page(a)bio.gla.ac.uk > > web: http://taxonomy.zoology.gla.ac.uk/rod/rod.html > > iChat: aim://rodpage1962 > > reprints: http://taxonomy.zoology.gla.ac.uk/rod/pubs.html > > > > Subscribe to Systematic Biology through the Society of Systematic > > Biologists Website: http://systematicbiology.org > > Search for taxon names: http://darwin.zoology.gla.ac.uk/~rpage/portal/ > > Find out what we know about a species: http://ispecies.org > > Rod's rants on phyloinformatics: http://iphylo.blogspot.com > > Rod's rants on ants: http://semant.blogspot.com > > > > > > > > ********************************************************************** > > > ** > > 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(a)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. > > > > ********************************************************************** > > > **** > > > > _______________________________________________ > > tdwg-guid mailing list > > tdwg-guid(a)lists.tdwg.org > > http://lists.tdwg.org/mailman/listinfo/tdwg-guid > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++ > WARNING: This email and any attachments may be confidential and/or > privileged. They are intended for the addressee only and are not to be read, > used, copied or disseminated by anyone receiving them in error. If you are > not the intended recipient, please notify the sender by return email and > delete this message and any attachments. > > The views expressed in this email are those of the sender and do not > necessarily reflect the official views of Landcare Research. > > Landcare Research > http://www.landcareresearch.co.nz > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++ > > > _______________________________________________ > tdwg-guid mailing list > tdwg-guid(a)lists.tdwg.org > http://lists.tdwg.org/mailman/listinfo/tdwg-guid > _______________________________________________ tdwg-guid mailing list tdwg-guid(a)lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-guid ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ WARNING: This email and any attachments may be confidential and/or privileged. They are intended for the addressee only and are not to be read, used, copied or disseminated by anyone receiving them in error. If you are not the intended recipient, please notify the sender by return email and delete this message and any attachments. The views expressed in this email are those of the sender and do not necessarily reflect the official views of Landcare Research. Landcare Research http://www.landcareresearch.co.nz ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

1 0

[tdwg-guid] RE: tdwg-guid Digest, Vol 5, Issue 5
by Jason Best 05 Jun '07

05 Jun '07

Thanks for all the responses and discussions. First I'll quickly answer some questions, then ask some more. Richard, when I say "collection" I mean "collection event". I'll try to be more precise in the future but, just as a warning, I'm bound to slip. Someone said something about incorporating the accession number into the LSID. You could do that, but it violates the "semantically opaque" aspect of the LSID identifier. Paul said: "Anybody got any views (strong, otherwise or proxy for others views) on whether the LSID should refer to data+metadata or just metadata?" I think Roger's response covers the issue, but I'll add my perspective. Ultimately, you need both (and this is my STRONG view). In our current situation, we have no need to resolve an LSID to data, only metadata for records that have no bytestream representation. That will change once we implement LSIDs for our images, documents and GIS files. Roger, I think your explanation is getting me closer to understanding how we should implement this, but I think I'll have to delve into RDF a bit more. Right now I'm thinking in database schemas and not RDF and I think the schema we have will allow the scenario you describe but I'd like to spell it out a little more just to make sure I understand it. I'm assuming when you say a "thing that changes", that will have a single LSID that does not change, but everything else about the "thing that changes" will change based upon the current version. So this is what I understand, in pseudo-RDF: ("Specimen_metadata" just represents the changing content, I just use different numbers to indicate this.) Specimen X Record LSID: Specimen_X_LSID versionedAs: Version_3_LSID Specimen_metadata: [567] Specimen X Version 1 LSID: Version_1_LSID isReplacedBy: Version_2_LSID Replaces: NULL isVersionOf: Specimen_X_LSID Specimen_metadata: [123] Specimen X Version 2 LSID: Version_2_LSID isReplacedBy: Version_3_LSID Replaces: Version_1_LSID isVersionOf: Specimen_X_LSID Specimen_metadata: [345] Specimen X Version 3 LSID: Version_3_LSID isReplacedBy: NULL Replaces: Version_2_LSID isVersionOf: Specimen_X_LSID Specimen_metadata: [567] Your description of "versionedAs" in your email seems pretty clear, so that is what I based the above on, but from the TDWG spec it is not so clear to me if I got it right. From what you say, it sounds like versionedAs would only point to one version of the metadata (the current version) but the description below makes it sound like a way to access older versions and would therefore have to be a listing of all the older versions. Or, does versionedAs go in the non-current versions and point to the unchanging LSID of the "thing that changes"? http://rs.tdwg.org/ontology/voc/Common#versionedAs "When the metadata linked to by this LSID is liable to change the LSID authority may choose to make an older version of the metadata available via another LSID. For some clients retrieving the version of the data current at a particular time (rather than the current metadata) may be important. By storing the value of the versionedAs LSID that is supplied with the current metadata they can be sure that they will always be able to refer to a particular version of the metadata. It is recommended that the DublinCore term isVersionOf is used to point from the versioned metadata to the principle LSID." Thanks for all the help! Jason

2 1

RE: [tdwg-guid] First step in implementing LSIDs?[Scanned]
by Kevin Richards 04 Jun '07

04 Jun '07

I think it would be best to completely ignore the idea LSID data, unless we have a strong use case for it. (I'm pretty sure we came to this conclusion after the GUID meetings). All "required" information should be in the metadata. The other issue here is how to "create" an LSID - what to use for the Object part of the LSID. If we use, for example, accession numbers, then the LSID does get "tied" to a particular dataset/database/organisation (the problem of moving objects from one organisation to another was also covered in the GUID meetings - see the GUID pages on the Wiki and the guid mailing list history for some rich discussion on these topics). So long as this issue has been considered when creating LSIDs, and they are guaranteed unique, I dont particularly see the problem with using the "accession number". Kevin >>> "Paul Kirk" <p.kirk(a)cabi.org> 06/02/07 10:14 PM >>> Yes Rich, our plan is to apply the LSID to the accession 'number' (actually an accession 'code' as we have an historical legacy of suffix 'a', 'b', etc for subdivisions of the original collection which in many cases is a collection of objects rather than one physical object - a bag of leaves for example). And yes, there are some possible problems with errors associated with the metadata but ... in the cotenxt of a DBMS where the accession number is set to unique values only, duplications are in reality impossible, and yes there are far more important challenges to address than this ... ;-) I assume you are correct about the 001100010011001000110011001101000011010100110110 ... I'm a systematist leaning towards nomenclature rather than an IT person. I guess the 'change of ownership' comment was directed at the importance of retaining the accession number as this is cited in the literature, and the utility of keeping this as a resolvable LSID. A rather complex model is required for 'managing' the objects of a collecting event and what subsequently happens to those objects, which others have more experience of and valid opinions on - I refer, for example, to a pit trap for insects where multiple objects are assigned an initial accession number, the objects are subsequently divided and divided again and again and finally a few may end up on pins as name bearing types. Cheers, Paul ________________________________ From: Richard Pyle [mailto:deepreef@bishopmuseum.org] Sent: Sat 02/06/2007 10:08 To: 'Paul Kirk'; 'Jason Best'; tdwg-guid(a)lists.tdwg.org Subject: RE: [tdwg-guid] First step in implementing LSIDs?[Scanned] Paul and List, First, I should clarify something about my earlier post. I wrote at the start of Scenario 3: "3) Issue data-less LSIDs without using the revision ID feature, and track data change history separately from the LSIDs" That should have been "...and track *metadata* change history separately from 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 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. So...if I understand correctly, you differ from my scenario 3 in that you do generate data-bearing LSIDs for specimens, but the data part is limited to only the Accession number, not the complete set of data fields associated with the record -- correct? So, in effect, the object LSID actially applies to is the binary accession number, not the "concept" of the specimen. I can imagine in this case that the LSID can be thought of as representing the "concept of the specimen" because the accession number itself is a surrogate for the physical specimen. The only thing that concerns me about this approach is that there is a non-zero incidence of accidental duplicate catalog numbers within a given collection, and possibly errors in associating catalog numbers. For example, if the computer database for a collection had an error created by a technician who, for example, entered the metadata for accession number IMI1234569 by mistake, when it should have been IMI1234596 (and vice versa), then branding the accession number as "data" for the LSID means that the LSID technically *must* stay with the accession number (not the specimen associated with the metadata for that LSID), after the error is discovered. Not a huge problem, but could surprise 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., they would get totally wrong information). Given how rare this problem is likely to be (against a backdrop of many far more likely problems we will have to overcome), I don't see this as a strong reason not to proceed with your plan. > 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. Is the binary data for the accession number in 8-bit, or 16-bit? I'm assuming 8-bit would be fine, as I suspect all collections would have accession numbers that can be rendered with 256-character ASCII. Is there any "wrapper" to the number as binary data, or is it a straight ASCII binary representation (e.g.: 001100010011001000110011001101000011010100110110 for "12345")? I'm not sure I follow the logic of how embedding the accession number as data for the LSID allows the LSID to move to a new owner. I would think the opposite. Isn't it likely that the new owner would create their own accession number for the specimen? In this case, they would be forced to generate a new LSID if they were following the same practice of encoding the accession number as "data", rather than metadata. Also, wouldn't it make more sense to include the acronym (IMI) as part of the 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 a strict 1:1 correlation between accession numbers and specimen objects for which an LSID is desired. Thanks for your comments -- this thread is already forcing me to think about things in a way I hadn't thought of them before. 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(a)bishopmuseum.org http://hbs.bishopmuseum.org/staff/pylerichard.html ************************************************************************ 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(a)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. ************************************************************************** ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ WARNING: This email and any attachments may be confidential and/or privileged. They are intended for the addressee only and are not to be read, used, copied or disseminated by anyone receiving them in error. If you are not the intended recipient, please notify the sender by return email and delete this message and any attachments. The views expressed in this email are those of the sender and do not necessarily reflect the official views of Landcare Research. Landcare Research http://www.landcareresearch.co.nz ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

1 0

[tdwg-guid] First step in implementing LSIDs?
by Jason Best 04 Jun '07

04 Jun '07

Greetings GUIDers, We are in the process of adding new functionality to our biodiversity database application that would include adding LSID "compliance" to our existing database of botanical collections. I have some questions about how the rest of the community is addressing some particular issues. I've read through the TDWG GUID Wiki and there seems to be some debate about how LSIDs should be applied to various entities in a system. I like the ideas I've read about "conceptual entities" and "hubs" because this lines up well with many of our ideas of how LSIDs could work for us. We do have a lot of images but right now our primary concern is with the collection metadata, so for the sake of this email, I'm going to exclude any questions about image or other bytecode. We will not be implementing an LSID resolver immediately, but we do want to make sure our schema and implementation of LSIDs will allow us a easy and seamless transition to having a proper resolver. At this stage, we are only concerned with assigning LSIDs to collections/collection events, specimens and versions of each. Since these aren't represented by bytecode we don't have to be concerned about issuing a new LSID each time the metadata changes (through improvements/changes in determination, geolocation etc), but we also don't want to throw away the previous revisions so the concept of a "hub" would serve well. This hub would allow us to have a single unchanging LSID that points to (or returns) the current metadata but also points to each LSID for the previous collection revisions. A change in the collection metadata would not change the LSID of the collection hub, it would just create a new collection version record which is issued a new LSID and promoted to "current". This collection hub would also point to a "hub" for each of the specimens that are represented by the collection and these specimen hubs would each point to the current metadata for the specimen as well as the previous versions. We would not be using the revision method of LSIDs, rather we would issue a totally new LSID for each version as recommended by TDWG. So the big questions are, 1) does this sound in line with the spec and 2) does this method of issuing LSIDs for "hubs" and revisions fit in with the approach others are taking? Any suggestions or caveats are appreciated. Thanks, Jason Jason Best IT Manager - Andes to Amazon Biodiversity Program Botanical Research Institute of Texas atrium.andesamazon.org

7 15

[tdwg-tapir] r1109 - tapir/dev/schema
by svn＠rs.tdwg.org 02 Jun '07

02 Jun '07

Author: RenatoDeGiovanni Date: 2007-06-03 00:03:24 +0200 (Sun, 03 Jun 2007) New Revision: 1109 Modified: tapir/dev/schema/tapir.xsd Log: Included the environment variables: dateCreated, metadataLanguage, dataSourceLanguage, dataSourceDescription, rights, subject, bibliographicCitation, technicalContactName, technicalContactEmail, contentContactName, contentContactEmail. Modified: tapir/dev/schema/tapir.xsd =================================================================== --- tapir/dev/schema/tapir.xsd 2007-06-02 21:37:20 UTC (rev 1108) +++ tapir/dev/schema/tapir.xsd 2007-06-02 22:03:24 UTC (rev 1109) @@ -700,7 +700,7 @@ </xsd:enumeration> <xsd:enumeration value="datasourceName"> <xsd:annotation> - <xsd:documentation>The name of the datasource (service title).</xsd:documentation> + <xsd:documentation>The name of the datasource (dc:title metadata).</xsd:documentation> </xsd:annotation> </xsd:enumeration> <xsd:enumeration value="accessPoint"> @@ -713,6 +713,61 @@ <xsd:documentation>Timestamp of the last update of the datasource.</xsd:documentation> </xsd:annotation> </xsd:enumeration> + <xsd:enumeration value="dateCreated"> + <xsd:annotation> + <xsd:documentation>Timestamp of the creation of the datasource.</xsd:documentation> + </xsd:annotation> + </xsd:enumeration> + <xsd:enumeration value="dataSourceDescription"> + <xsd:annotation> + <xsd:documentation>The description of the datasource (dc:description metadata).</xsd:documentation> + </xsd:annotation> + </xsd:enumeration> + <xsd:enumeration value="rights"> + <xsd:annotation> + <xsd:documentation>Information about who can access the resource or about its security status, access regulations, etc. (dc:rights metadata).</xsd:documentation> + </xsd:annotation> + </xsd:enumeration> + <xsd:enumeration value="subject"> + <xsd:annotation> + <xsd:documentation>Keywords, key phrases or classification codes that describe content provided by the resource (dc:subject metadata).</xsd:documentation> + </xsd:annotation> + </xsd:enumeration> + <xsd:enumeration value="bibliographicCitation"> + <xsd:annotation> + <xsd:documentation>Information about how to cite the datasource (dc:bibliographicCitation metadata).</xsd:documentation> + </xsd:annotation> + </xsd:enumeration> + <xsd:enumeration value="metadataLanguage"> + <xsd:annotation> + <xsd:documentation>The language in which the content of the following variables are expressed: datasourceName, dataSourceDescription, rights, subject and bibliographicCitation.</xsd:documentation> + </xsd:annotation> + </xsd:enumeration> + <xsd:enumeration value="dataSourceLanguage"> + <xsd:annotation> + <xsd:documentation>The primary language of the data provided by the service (dc:language metadata).</xsd:documentation> + </xsd:annotation> + </xsd:enumeration> + <xsd:enumeration value="technicalContactName"> + <xsd:annotation> + <xsd:documentation>The name of the first system administrator of the first technical host entity.</xsd:documentation> + </xsd:annotation> + </xsd:enumeration> + <xsd:enumeration value="technicalContactEmail"> + <xsd:annotation> + <xsd:documentation>The e-mail of the first system administrator of the first technical host entity.</xsd:documentation> + </xsd:annotation> + </xsd:enumeration> + <xsd:enumeration value="contentContactName"> + <xsd:annotation> + <xsd:documentation>The name of the first data administrator of the first data supplier entity.</xsd:documentation> + </xsd:annotation> + </xsd:enumeration> + <xsd:enumeration value="contentContactEmail"> + <xsd:annotation> + <xsd:documentation>The e-mail of the first data administrator of the first data supplier entity.</xsd:documentation> + </xsd:annotation> + </xsd:enumeration> </xsd:restriction> </xsd:simpleType> <xsd:simpleType name="variableNameType">

1 0

[tdwg-tapir] r1108 - tapir/dev/schema
by svn＠rs.tdwg.org 02 Jun '07

02 Jun '07

Author: RenatoDeGiovanni Date: 2007-06-02 23:37:20 +0200 (Sat, 02 Jun 2007) New Revision: 1108 Modified: tapir/dev/schema/tapir.xsd Log: Included optional attribute "alias" in output models and query templates that are advertised in capabilities responses. Modified: tapir/dev/schema/tapir.xsd =================================================================== --- tapir/dev/schema/tapir.xsd 2007-05-31 12:37:54 UTC (rev 1107) +++ tapir/dev/schema/tapir.xsd 2007-06-02 21:37:20 UTC (rev 1108) @@ -886,7 +886,15 @@ <xsd:element name="knownOutputModels" minOccurs="0" > <xsd:complexType> <xsd:sequence> - <xsd:element name="outputModel" type="externalResourceType" maxOccurs="unbounded"/> + <xsd:element name="outputModel" maxOccurs="unbounded"> + <xsd:complexType> + <xsd:complexContent> + <xsd:extension base="externalResourceType"> + <xsd:attribute name="alias" type="xsd:string"/> + </xsd:extension> + </xsd:complexContent> + </xsd:complexType> + </xsd:element> </xsd:sequence> </xsd:complexType> </xsd:element> @@ -1068,6 +1076,7 @@ <xsd:complexType> <xsd:complexContent> <xsd:extension base="externalResourceType"> + <xsd:attribute name="alias" type="xsd:string"/> <xsd:attribute name="wsdl" type="xsd:anyURI"> <xsd:annotation><xsd:documentation>URL pointing to a WSDL file describing this template interface</xsd:documentation></xsd:annotation> </xsd:attribute>

1 0

[tdwg-guid] LSID on subobjects of composite objects
by Bob Morris 02 Jun '07

02 Jun '07

On 6/2/07, Weitzman, Anna <WEITZMAN(a)si.edu> wrote: >[7 related 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. > > In an earlier posting today, I said I don't know what Anna means by "parent LSID", but here I will take a guess because if right, it relates to a problem put on the table last year at the Edinburgh GUID workshop and never resolved. I suspect what is meant is that there is something needing a GUID, e.g. an element deep in a highly marked-up legacy publication, and that the resolution for that GUID should clearly show the relation to the GUID of the thing containing it. The general issue is how should the GUIDs of parts of composites be related to the GUID of the composite, and how should it be determinable that the relation is that of component to composite. As in my earlier posting, this is probably easily described in the TDWG ontology and perhaps needs mainly a recommendation of how to do so. Or maybe there already is. Bob Morris

1 0