January 2006 - tdwg-tag - lists.tdwg.org

Re: identifiers for geologic samples
by Robert Huber 30 Jan '06

30 Jan '06

Dear all, The discussion on identifiers on geosamples is still open. Some of the major earth science related data centers (eg. us) would prefer a decentralized technology and real GUIDs. Eg. the IODP (one of the major international earth science programs) is thinking about introducing GUIDs for their samples (cores, core sections and samples). I think I have noticed that already a couple of weeks ago in a WIKI comment, next time I will place such info on a more prominent place... Kerstin is one of the co-convenors of the EGU session in Vienna, April I recently asked for contributions. So there already are some relations between SESAR and the taxon GUID group. best regards, Robert > -----Ursprüngliche Nachricht----- > Von: Taxonomic Databases Working Group GUID Project > [mailto:TDWG-GUID@LISTSERV.NHM.KU.EDU]Im Auftrag von Matt Jones > Gesendet: Samstag, 28. Januar 2006 00:56 > An: TDWG-GUID(a)LISTSERV.NHM.KU.EDU > Betreff: identifiers for geologic samples > > > The earlier discussion on samples was valuable, especially regarding the > subsample/part-of issues when samples are taken apart and the > relationships need to be maintained. I saw a talk in the last two weeks > by Kerstin Lehnert about the use of identifiers for geologic samples. > They seem to have many of the same issues that we do for biological > samples. They have created a system called the "International Geo > Sample Number", which is a centralized sample registration service. > Interestingly, they invented their own syntax rather than using a > standard like LSID or DOI. I though it might be interesting background > for those of you going to the meeting next week: > > http://www.geosamples.org/ > > and here's a fossil plant sample as displayed in their registry: > > http://www.geosamples.org/applications/sesarSearch/view_sample.jsp > > Matt > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Matt Jones Ph: 907-789-0496 > jones(a)nceas.ucsb.edu SIP #: 1-747-626-7082 > National Center for Ecological Analysis and Synthesis (NCEAS) > UC Santa Barbara http://www.nceas.ucsb.edu/ecoinformatics > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

Combined response
by Richard Pyle 30 Jan '06

30 Jan '06

Rod Page wrote: > The issue of centralisation and "taxonomic freedom" is a red herring > (due to Rich and I talking past each other -- my fault). I share the blame. > My concern > (and I know I'm doing a very poor job of explaining this) is that > administrative layers and attempting to harmonise things centrally may > ultimately prove to get in the way of getting things done. I agree that it might, but I don't think it necessarily has to. Again, I point to IP addresses and DNS. They are obviously harmonized, but aren't locked up in administrative layers (or are they???) Arthur Chapman wrote: > To some extent I think Sally is right, what she suggests > wouldn't improve things with respect to duplicate specimens > however- specimens of the same collection sent to more than one > (and some times many) different institutions. And Sally Hinchcliffe responded: > > regarding duplicates, to my mind, there's a very strong connection > > between the duplicate of 'Chapman 541' held at Kew and the one held > > at Canberra (assuming there is such a thing). But they aren't the > > same thing (and shouldn't have the same id) - a photograph of Kew's > > duplicate would look nothing like a photograph of Canberra's > > duplicate for example. I'm not sure whether GUIDs are going to help > > us solve the problem of duplicates although I agree that it's > > desirable. What _could_ have the same GUID is the collecting event > > (Chapman taking a specimen) that gave rise to the two specimens ... > > but who or what would issue or control _those_ GUIDs? It depends on what object the GUID is attached to: the preserved specimen in a Museum; or the individual organism from what the specimen was extracted. If the former, they need separate GUIDs. If the latter, they may still need separate "Museum specimen" GUIDs (for tracking museum-specimen-related stuff), but may also need to both point to a common "individual organism" GUID and/or a common "collecting event" GUID. Chuck Miller wrote: > An issue that needs to be decided by the workshop is how much > "abstraction" of a GUID is absolutely necessry if it must also be > locatable through the Internet? That is, is a compromise needed > to allow embedding of domain names in order to enable use of the > DNS to locate GUIDs. Surely there is insufficient time, funds, > and staff to embark upon creation of a master switchboard (database) > where the locations of millions of GUIDs are recorded and updated > in perpetuity. I think we can have the best of both worlds, and I don't think we need a master switchboard keeping track of the locations of millions of GUIDs. If GBIF or TDWG or some other similar organisation would simply provide a service where anyone can self-register and reserve a block of 64-bit integers, then those of us who wish to do so may substitute our own internal ID numbers with corresponding values from the reserve block. That way, we can present them as part of an LSID, or handle system, or the terminal bit of whatever GUID system is used, knowing with confidence that nobody else out there will use the same integer for any ID value within the TDWG/GBIF/bioinformatics universe. The organization in charge of keeping track of which clients reserved which blocks of numbers would *not* need to track what data objects those individual numbers are assigned to. In fact, I suspect that the majority of those numbers would never get assigned to anything. But those that do get assigned, would be guaranteed to be unique (by themselves) within the TDWG/GBIF/bioinformatics scope. With that in place, an LSID or DOI-like Handle GUID would serve as a contextual "wrapper" around a core unique ID number (a number that could transcend any particular GUID resolution system). Donald Hobern wrote: ...a very helpful and thoughtfully-framed post, which I will think about during my plane ride tonight. See you all in a couple days.... Aloha, Rich

1 0

Re: How GUIDs will be used
by Richard Pyle 30 Jan '06

30 Jan '06

> I'm not worried about centralised taxonomy, I'm simply wondering who is > going to do all this work of deciding what GUID gets allocated for, > say, a name The same people who would do the work in your scenario. It's just that they would check to see if the name(s) had already been assigned GUIDs before assigning new ones. > Yes, in some cases things are simple. For example, we could simply ask > uBio to store every name string (which is pretty much what they are > doing already), and use their ids as the basis of name GUIDs. But > mapping between some of the "higher-level" name databases is not > trivial. I agree it's not trivial -- which is why I think it would best be done as a coordinated effort, rather than multiple independant efforts -- so that we're not stuck with the non-trivial task of managing all those duplicate GUIDs. And in my ideal world, the full dataset would not live on only one server. It would live in replicated form across hundreds of servers, with robust synchronization protocols. > Are IPNI and MOBOT going to sit down and go through their databases and > match things up, are we then going to do the same thing with IPNI, > MOBOT, NCBI and TreeBASE? We would have to do this iteratively like that if they all created they're own public GUIDs for the same set of names. If they were coordinated about it, each dataset would have to be mapped to a single common GUID-set only once. > Will we wait until this is done before > assigning GUIDs? And given that mapping between databases can be > contentious (is this name really the same as that name, how do we know, > etc.) -- and I should point out that current attempts to do this, such > as NCBI's LinkOut which uses names are riddled with errors -- it seems > this is knowledge that will evolve over time. I guess my point is that the Name+Author strings alone (sans GUIDs) serve almost the same function as individual-provider-assigined GUIDs would, in the case of taxon names. It seems to me that the GUIDs only become really useful when they are used to unambiguously cross-link multiple datasets together. So I don't see how publicly exposing provider-assigned GUIDs (with multiple redundancies) does anything useful for us beyond what we already can do when the providers expose Name+Author strings -- that is, the GUIDs really only serve as an extra layer. > In the same vain, I suggest that we are likely to make more progress > if we have resolvable GUIDs now so that major data sources open their > data up, then we use data mining tools to go in an finding mappings, > inconsistencies, etc. Many of these things can be computed, i.e. can be > automated. Being open could encourage anybody to have a go at examining > mappings. > > I'm probably being wildly naive, but I think concern for getting it > "right" might get in the way of getting it "done". Fair enough -- I don't disagree with that concern at all (in fact I share it quite strongly -- I'm a huge fan of getting it done). Any passion I may have expressed in this or recent posts is a passion not to be misunderstood -- not a passion for centralized/coordinated GUIDs for shared data objects. The only thing I'm adamant about is keeping an open mind about this stuff, and keeping my personal biases in check. > Ducks incoming flames/brickbats/etc. Definitely not from me! As I have said before, I think the amount we agree on vastly exceeds what we disagree on -- and even where we both disagree, we really only lie on different positions of the same continuum. Aloha, Rich

1 0

How GUIDs will be used
by Sally Hinchcliffe 30 Jan '06

30 Jan '06

Something I was thinking about over the weekend (I really must get a life) I was just reading the California Digital Library paper on ARK identifiers (I think it got circulated many moons ago, yes I am just getting caught up on my 'homework' now...) and the following assertion stood out: (page 3) '[W]hat we're looking for are persistent actionable identifiers, where an actionable identifier is one that widely available tools such as web browsers can use to convert a simple "click" into access to the object ...' This strikes me as only half true. For specimens, yes, most of the use of GUIDs will be ultimately to allow a user to get their hands on either the specimen itself or an electronic object sufficiently informative about the specimen (e.g. a picture or a grid ref) that they can do something scientific with it. In that case it mostly doesn't matter if one specimen has multiple different ids (due to aggregations, splittings, derivatives, sampling etc.) as long as all of those ids lead back to the same thing. But for the more abstract things like names, concepts and maybe even descriptive terms, I can imagine the guids themselves becoming widely used without there ever (or very rarely) being a reference made back to the source of the id because there's not much more _there_ (other than confirmation that no mistakes have been made in transmitting the id). The real benefit of _these_ GUIDs is in being able to make machine-computable statements about x being the same as or different to or composed of y. In this case, multiple guids referring to the same thing does become a problem because each duplication dilutes the amount of information carried by that GUID as to whether x truly is different from y, and reduces the chance that two of the same things will carry the same id. Does this make sense? It suggests that the delegation model for specimens (e.g. just let each collection issue its own ids for anything it likes) might have to differ from the one for names, concepts or other largely abstract objects (where we might want to explicitly divvy out the domains to particular nomenclators, concept banks and so on) Sally *** Sally Hinchcliffe *** Computer section, Royal Botanic Gardens, Kew *** tel: +44 (0)20 8332 5708 *** S.Hinchcliffe(a)rbgkew.org.uk

1 0

Re: identifiers for geologic samples
by Sally Hinchcliffe 30 Jan '06

30 Jan '06

Rod wrote: > On 28 Jan 2006, at 01:02, Richard Pyle wrote: > > > The more I think about it, the more I think this is the sort of system > > that > > would work well for our field. A centralized issuer (which could issue > > blocks of thousands or millions of numbers at a time), > > The major problem I see with this is that a central registry may be a > rate limiting step because it has to allocate blocks, it would also > decide for format of the last part of the identifier (which the > provider might not find desirable), and it may well lead to lots of > wasted identifiers (e.g., it allocates 100,000 to me, but I use 3 off > them). > > Would it not be better to devolve this? You can still have a central > registry. For example, Handles and DOIs work by having a central > registry for the prefix (e.g., "1018") and the provider is responsible > for allocating the suffix locally. > I agree - and with provider allocation of ids, we allow providers (and users) to continue to use existing or legacy ids without having any extra step of lookups to find out what the 'real' id is. *** Sally Hinchcliffe *** Computer section, Royal Botanic Gardens, Kew *** tel: +44 (0)20 8332 5708 *** S.Hinchcliffe(a)rbgkew.org.uk

1 0

Re: identifiers for geologic samples
by Roderic Page 30 Jan '06

30 Jan '06

Bob is confusing me with somebody who reads standards (what they?). Firstly, I think having an Internet domain name in an identifier pretty much kills any claim to be semantically opaque, regardless of what one does in the namespace and identifier parts of the LSID. Secondly, it seems to me that the reality is that LSID resolution depends on the DNS, and on users mucking with SRV records. Section 13 of the spec goes on at great lengths about the DNS. The spec discusses an alternative (Dynamic Delegation Discovery Service -- DDDS) that relies on a central authority (lsidauthority.org), which as far as I can tell doesn't exist (unlike the equivalent for handles). Handles and ARK in particular have thought about life after/without the DNS, but LSIDs seem only to pay lip service to this. I'm not very anti LSIDs, indeed arguably I've spent more time than most (publicly) playing with them (leaving aside the guys at IBM, EBI, etc. who programmed the underlying code). My rethink came about when Donat Agosti started urging me to look at setting up GUIDs for AntBase publications. DOIs are out because of cost. Do I recommend LSIDs? Well, does Donat to muck with the DNS (or get a systems admin to do it)? And once he's done so, who can use his LSIDs anyway? Nobody really, part from script jockeys like me. Much as it pains me greatly, I don't think I can tell Donat to use LSIDs. So I took a peek at some other alternatives (mostly covered already on the TDWG-GUID wiki, but see my notes at http://ispecies.blogspot.com/2006/01/identifiers-for- publications.html), and in terms of speed and easy of use was going to suggest static URLs would work fine for Donat's purposes, at least in the short term, (especially as we'd like to get something working ASAP because a lot of things down the line depend on this). However, then I got hold of the handle system, had a play, and after the usual pain of dealing with Java on Fedora Core 4, got it working. This caused me to rethink handles. To my mind, the big plus of LSIDs lies in the explicit definition of an interface for getting metadata and for getting data. DOIs and Handles are essentially a free-for-all (do they resolve to data, metadata, will what I see depend on whether I'm at home or at my place of work, will I need a subscription to see the data, etc.). The actual identifier part of the LSID spec I'm less struck on. Now, we could make sure our handles resolved to something meaningful in a standard way, and get most of the cool features of LSIDs for free. A very simple, lightweight way to do this is have them simply resolve to RDF in XML format. This could be transformed into HTML or whatever. Indeed, with modern web browsers, we could serve XML and have the browser automatically render it in HTML. This would mean users could see HTML, but scripts could access RDF, using exactly the same point of access. For a demo, see the handle hdl:2254/20971, which can be resolved here: http://hdl.handle.net/2254/20971 . What you'll see in a modern browser is HTML, but if you "view source" it's just RDF. Call me sad, but I find this pretty neat. All I'm suggesting is that, as cool as LSIDs are, and as much as I have devoted a lot of effort to getting some working, I'm not convinced they are the way to go. My final question in all this is: if LSIDs are really so cool, why is it that the EBI and NCBI have no publicly available LSID services (or even private ones)? Why is it that apart from some ecologists in Wisconsin, the only people taking LSIDs seriously (by which I mean, writing code) as far as I can see are BioMoby and MyGrid, both largely academic projects that are cool, but are not major data providers. Thus endith the rant. Rod On 30 Jan 2006, at 03:04, Bob Morris wrote: > >From my understanding of the LSID spec, LSIDs do not rely on the DNS. > Rather one particular mechanism for discovering resolution services > depends on the DNS, and nothing in the LSID specification requires the > use of that mechanism, convenient as it presently may be. Future > resolution service discovery mechanisms can use the existing LSID as > they please provided only they meet the specification of a resolution > service discovery service. > > Also, LSIDs are required by the spec to be semantically opaque. > Though, this has some exceptions, and semantic opacity is narrowly > defined, I would say that except for resolution service discovery > services---and such services that use DNS are narrowly constrained by > the spec---, those applications that ascribe meaning to parts of an > LSID are probably guilty of violating the spec and perhaps don't > deserve that much sympathy. > > cf Section 8 and Section 13.3 of > http://www.omg.org/docs/dtc/04-05-01.pdf > > I hope that those who argue against LSIDs on either of the above two > grounds will place in the wiki (or point me to where it already is) > how I am misreading the spec.If I am reading it correctly, I don't > understand how the arguments Rod puts forth here would lead to > rejection of LSID whatever other disadvantages it may have compared to > alternatives. > > This is a familiar sounding point and maybe somebody answered me the > last time I whined about it, long ago in a mailing list far, far away. > My apologies if so. > > Bob Morris > > > On 1/28/06, Roderic Page <r.page(a)bio.gla.ac.uk> wrote: On 28 Jan 2006, > at 01:02, Richard Pyle wrote: >> >> > The more I think about it, the more I think this is the sort of >> system >> > that >> > would work well for our field. A centralized issuer (which could >> issue >> > blocks of thousands or millions of numbers at a time), >> >> The major problem I see with this is that a central registry may be a >> rate limiting step because it has to allocate blocks, it would also >> decide for format of the last part of the identifier (which the >> provider might not find desirable), and it may well lead to lots of >> wasted identifiers ( e.g., it allocates 100,000 to me, but I use 3 off >> them). >> >> Would it not be better to devolve this? You can still have a central >> registry. For example, Handles and DOIs work by having a central >> registry for the prefix ( e.g., "1018") and the provider is >> responsible >> for allocating the suffix locally. >> >> >> > I'm not sure how wise it would be to create a new syntax standard, >> > rather >> > than go with one of the ones we've discussed. But if (for example) >> > using >> > LSID, I personally think it would be preferable to establish a >> highly >> > generic form, such as: >> > >> > urn:lsid:gbif.org:BioGUID:12345 >> >> Without wishing to preempt some of the things I'm going to present at >> the workshop, I'm going off LSIDs a little because of their reliance >> on >> the Internet DNS. Apart from the hassle of mucking with the DNS >> records >> to set them up (I suspect not every provider is going to find this >> easy >> to do), it assumes that the Internet its present form is going to be >> here forever, and it also embeds information in the identifier (e.g., >> "gbif.org") that currently has meaning, but over time may loose >> meaning, or worse, be positively misleading (say if GBIF goes belly up >> and somebody else serves the data). >> >> Handles (including DOIs) and ARK have no information in the identifier >> (perhaps not strictly true for some DOIs, but that's by choice not >> design), and also in principle don't need the internet. In the future >> some other mode of information transport may come along, and they >> could >> still be used. >> >> While it might be hard to imagine the Internet and the DNS going away, >> if anybody has a 5 1/4" floppy lying around, they'll be aware of how >> hard it is to get information off it these days as 5 1/4" drives are >> scarce as hens teeth -- the only one in my department is in an old PC >> that is connected to the network. The digital library community seem >> particularly sensitive to these issues, which is perhaps why they use >> handles, DOIs, and ARK. >> >> Regards >> >> Rod >> >> >> >> ---------------------------------------------------------------------- >> -- >> ---------------------------------------- >> 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 >> 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 at >> http://darwin.zoology.gla.ac.uk/~rpage/portal/ >> Find out what we know about a species at http://ispecies.org >> >> >> >> >> >> >> ___________________________________________________________ >> Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with >> voicemail http://uk.messenger.yahoo.com >> ------------------------------------------------------------------------ ---------------------------------------- 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 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 at http://darwin.zoology.gla.ac.uk/~rpage/portal/ Find out what we know about a species at http://ispecies.org ___________________________________________________________ Yahoo! Photos NEW, now offering a quality print service from just 8p a photo http://uk.photos.yahoo.com

1 0

Re: How GUIDs will be used
by Arthur Chapman 29 Jan '06

29 Jan '06

To some extent I think Sally is right, what she suggests wouldn't improve things with respect to duplicate specimens however- specimens of the same collection sent to more than one (and some times many) different institutions. One of the strengths of having those collections linked in some way through GUIDS is that it would aid considerably in quality control. Also cut down considerably the need to duplicate such things as georeferencing and validation. There are also many analyses where true replicates want to be deleted from the analysis, otherwise they may bias the results. So even if we have institutions issuing their own GUID numbers, we will need a method of 'synonymisation' etc. The other issue is with names - if it is ONLY names we were loooking to add GUIDs to, then we have a nomenclature system already. Where the strength lays is in that part of the taxonomy where no coding system exists - for the taxon concept. Contrary to some, I son't see some form of centralised issuing authority restricting taxonomy and taxonomic freedom any more than a register of Births, Deaths and Marriages restricts your ability to name your child anyway you wish. My tuppence worth! Arthur Arthur Chapman Australian Biodiversity Information Services Toowoomba, Qld, Australia >>>From Sally Hinchcliffe <S.Hinchcliffe(a)KEW.ORG> on 30 Jan 2006: > Something I was thinking about over the weekend (I really must get a > life) > > I was just reading the California Digital Library paper on ARK > identifiers (I think it got circulated many moons ago, yes I am just > getting caught up on my 'homework' now...) and the following > assertion stood out: (page 3) > > '[W]hat we're looking for are persistent actionable identifiers, > where an actionable identifier is one that widely available tools > such as web browsers can use to convert a simple "click" into access > to the object ...' > > This strikes me as only half true. For specimens, yes, most of the > use of GUIDs will be ultimately to allow a user to get their hands on > either the specimen itself or an electronic object sufficiently > informative about the specimen (e.g. a picture or a grid ref) that > they can do something scientific with it. In that case it mostly > doesn't matter if one specimen has multiple different ids (due to > aggregations, splittings, derivatives, sampling etc.) as long as all > of those ids lead back to the same thing. > > But for the more abstract things like names, concepts and maybe even > descriptive terms, I can imagine the guids themselves becoming widely > used without there ever (or very rarely) being a reference made back > to the source of the id because there's not much more _there_ (other > than confirmation that no mistakes have been made in transmitting the > id). The real benefit of _these_ GUIDs is in being able to make > machine-computable statements about x being the same as or different > to or composed of y. In this case, multiple guids referring to the > same thing does become a problem because each duplication dilutes the > amount of information carried by that GUID as to whether x truly is > different from y, and reduces the chance that two of the same things > will carry the same id. > > Does this make sense? It suggests that the delegation model for > specimens (e.g. just let each collection issue its own ids for > anything it likes) might have to differ from the one for names, > concepts or other largely abstract objects (where we might want to > explicitly divvy out the domains to particular nomenclators, concept > banks and so on) > > Sally > *** Sally Hinchcliffe > *** Computer section, Royal Botanic Gardens, Kew > *** tel: +44 (0)20 8332 5708 > *** S.Hinchcliffe(a)rbgkew.org.uk >

1 0

Re: How GUIDs will be used
by Richard Pyle 29 Jan '06

29 Jan '06

Hi Rod, > To me centralisation is red rag to a bull, especially as the objects of > interest (names and concepts) are things we might reasonably disagree > over. Please don't misunderstand what I'm talking about here. Of course we might reasonably disagree over which names to regard as valid and which to regard as synonyms. We will also disagree about the scope of organisms to include within the circumscription of a taxon concept. However, in most cases, we will not disagree that Smith (1955) described the species "bus", and placed it in the genus "Aus" (i.e., the taxon name object "Aus bus Smith 1955"); or that Jones (1975) regarded Smith's "Aus bus" as a junior synonym of Brown's (1935) "Aus xus" (i.e., the taxon concept object "Aus xus Brown 1935 SEC Jones 1975"; the circumscription of which includes the taxon concept object "Aus bus Smith 1955 SEC Smith 1955"). Centralizing the issuance of GUIDs for things like taxon name objects and concepts/usage instances does NOT, in any way, centralize "taxonomy". It simply serves to avoid issuing 150 different GUIDs for the taxon name object "Aus bus Smith 1955" -- one GUID from each of 150 different data providers that happen to list that name in their taxonomic authority table. > Why not let users decide this, by which I mean, if a provider > comes up with a comprehensive list of names with good supporting > metadata, users will gravitate towards using them. There will also be a > "market" for people building services that map between GUIDs (I'm > thinking of making one for TreeBASE, for example). Why centralise this > activity? So that we don't need a "market" for services to cross-map duplicate GUIDs that never needed to be created in the first place. Instead, we should "market" services that utilize a common/shared set of GUIDs for objective name objects (and concept/usage objects) to assist *taxonomy*. (And, in the shorter term, market tools that allow data providers to cross-map their internal taxonomic authorities to shared GUIDs.) We certainly can't eliminate duplicates, but at least we can try to minimize the unnecessary duplicates. I spend an inordinate chunk of my time doing two things that I should not have to do: 1) cross-mapping large datasets to a common shared authority (like taxon names); and 2) cleaning up the database messes created by earlier workers who were pressed for time, and opted for the quick & dirty solution. Frankly, I'm not sure why we even need GUIDs for things like Taxon Names, other than to mitigate these two kinds of problems. I thought the point was to facilitate electronic information flow. How have we facilitated electronic information flow if you assign one GUID for "Aus bus Smith 1955", and I assign another GUID to the same taxon name, and a pair of human eyes is required to ascertain that they are, indeed, two pointers to the same abstract data object? > I see the point that multiple GUIDs for the same thing can be > a pain (for papers we have DOIs, PubMed ids, Google Scholar ids, DSpace > handles, etc.), but in the end centralised GUID assignment reeks of > committees, etc., in other words, impediments to actually getting > things done. Again, please do not confuse the idea of centralized (or at least coordinated) issuance of GUIDs for unambiguously shared data objects (like taxon name objects), with some sort of ill-advised centralized effort for a "shared taxonomy". I have not seen anybody in recent years even suggest the possibility of the latter. > I agree that software tools to "cross-walk multiple > independent datasets with broadly overlapping data objects" would be > very nice, but let's separate this from centralising GUID assignment. > One of the lessons of the web, IMHO, is that centralisation doesn't > scale. You can't scale much bigger than the global pool of IP addresses which are, ultimately, issued in blocks in a coordinated, semi-centralized way (not althogether unlike a model of GUID issuance that I have previously suggested). Aloha, Rich Richard L. Pyle, PhD Database Coordinator for Natural Sciences 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

1 0

Re: How GUIDs will be used
by Richard Pyle 29 Jan '06

29 Jan '06

Thank you, Sally! I have been beating the drums on a related point (the difference between data objects singlularly associated with particular organisations, people or projects -- like specimens and datasets; vs. data objects likely to be shared by many -- like taxon names & concepts, reference citations, and named localities) for years now. Your observation of other practical differences relating to the impact of GUID duplication further emphasizes the distinction. Perhaps the two break-out sections at the workshop should be split according to "GUIDs for data objects not likely to be duplicated across multiple providers" (existing "specimens" group), vs. "GUIDs likely to be shared by multiple providers" (existing taxon names/concepts group). I would imagine that the former group would lean toward provider-assigned GUIDs and emphasis on fast/easy implementation; whereas the latter group would lean towards centralized GUID assignment (or at least coordination of GUID assignment) and emphasis on developing software tools to cross-walk multiple independent datasets with broadly overlapping content of shared data objects, in order to minimize redundant GUID assignment to shared objects. Aloha, Rich > -----Original Message----- > From: Taxonomic Databases Working Group GUID Project > [mailto:TDWG-GUID@LISTSERV.NHM.KU.EDU]On Behalf Of Sally Hinchcliffe > Sent: Sunday, January 29, 2006 11:13 PM > To: TDWG-GUID(a)LISTSERV.NHM.KU.EDU > Subject: How GUIDs will be used > > > Something I was thinking about over the weekend (I really must get a > life) > > I was just reading the California Digital Library paper on ARK > identifiers (I think it got circulated many moons ago, yes I am just > getting caught up on my 'homework' now...) and the following > assertion stood out: (page 3) > > '[W]hat we're looking for are persistent actionable identifiers, > where an actionable identifier is one that widely available tools > such as web browsers can use to convert a simple "click" into access > to the object ...' > > This strikes me as only half true. For specimens, yes, most of the > use of GUIDs will be ultimately to allow a user to get their hands on > either the specimen itself or an electronic object sufficiently > informative about the specimen (e.g. a picture or a grid ref) that > they can do something scientific with it. In that case it mostly > doesn't matter if one specimen has multiple different ids (due to > aggregations, splittings, derivatives, sampling etc.) as long as all > of those ids lead back to the same thing. > > But for the more abstract things like names, concepts and maybe even > descriptive terms, I can imagine the guids themselves becoming widely > used without there ever (or very rarely) being a reference made back > to the source of the id because there's not much more _there_ (other > than confirmation that no mistakes have been made in transmitting the > id). The real benefit of _these_ GUIDs is in being able to make > machine-computable statements about x being the same as or different > to or composed of y. In this case, multiple guids referring to the > same thing does become a problem because each duplication dilutes the > amount of information carried by that GUID as to whether x truly is > different from y, and reduces the chance that two of the same things > will carry the same id. > > Does this make sense? It suggests that the delegation model for > specimens (e.g. just let each collection issue its own ids for > anything it likes) might have to differ from the one for names, > concepts or other largely abstract objects (where we might want to > explicitly divvy out the domains to particular nomenclators, concept > banks and so on) > > Sally > *** Sally Hinchcliffe > *** Computer section, Royal Botanic Gardens, Kew > *** tel: +44 (0)20 8332 5708 > *** S.Hinchcliffe(a)rbgkew.org.uk

1 0

Re: identifiers for geologic samples
by Bob Morris 29 Jan '06

29 Jan '06

>>>From my understanding of the LSID spec, LSIDs do not rely on the DNS. Rather one particular mechanism for discovering resolution services depends on the DNS, and nothing in the LSID specification requires the use of that mechanism, convenient as it presently may be. Future resolution service discovery mechanisms can use the existing LSID as they please provided only they meet the specification of a resolution service discovery service. Also, LSIDs are required by the spec to be semantically opaque. Though, this has some exceptions, and semantic opacity is narrowly defined, I would say that except for resolution service discovery services---and such services that use DNS are narrowly constrained by the spec---, those applications that ascribe meaning to parts of an LSID are probably guilty of violating the spec and perhaps don't deserve that much sympathy. cf Section 8 and Section 13.3 of http://www.omg.org/docs/dtc/04-05-01.pdf I hope that those who argue against LSIDs on either of the above two grounds will place in the wiki (or point me to where it already is) how I am misreading the spec.If I am reading it correctly, I don't understand how the arguments Rod puts forth here would lead to rejection of LSID whatever other disadvantages it may have compared to alternatives. This is a familiar sounding point and maybe somebody answered me the last time I whined about it, long ago in a mailing list far, far away. My apologies if so. Bob Morris On 1/28/06, Roderic Page <r.page(a)bio.gla.ac.uk> wrote: > > On 28 Jan 2006, at 01:02, Richard Pyle wrote: > > > The more I think about it, the more I think this is the sort of system > > that > > would work well for our field. A centralized issuer (which could issue > > blocks of thousands or millions of numbers at a time), > > The major problem I see with this is that a central registry may be a > rate limiting step because it has to allocate blocks, it would also > decide for format of the last part of the identifier (which the > provider might not find desirable), and it may well lead to lots of > wasted identifiers (e.g., it allocates 100,000 to me, but I use 3 off > them). > > Would it not be better to devolve this? You can still have a central > registry. For example, Handles and DOIs work by having a central > registry for the prefix (e.g., "1018") and the provider is responsible > for allocating the suffix locally. > > > > I'm not sure how wise it would be to create a new syntax standard, > > rather > > than go with one of the ones we've discussed. But if (for example) > > using > > LSID, I personally think it would be preferable to establish a highly > > generic form, such as: > > > > urn:lsid:gbif.org:BioGUID:12345 > > Without wishing to preempt some of the things I'm going to present at > the workshop, I'm going off LSIDs a little because of their reliance on > the Internet DNS. Apart from the hassle of mucking with the DNS records > to set them up (I suspect not every provider is going to find this easy > to do), it assumes that the Internet its present form is going to be > here forever, and it also embeds information in the identifier (e.g., > "gbif.org") that currently has meaning, but over time may loose > meaning, or worse, be positively misleading (say if GBIF goes belly up > and somebody else serves the data). > > Handles (including DOIs) and ARK have no information in the identifier > (perhaps not strictly true for some DOIs, but that's by choice not > design), and also in principle don't need the internet. In the future > some other mode of information transport may come along, and they could > still be used. > > While it might be hard to imagine the Internet and the DNS going away, > if anybody has a 5 1/4" floppy lying around, they'll be aware of how > hard it is to get information off it these days as 5 1/4" drives are > scarce as hens teeth -- the only one in my department is in an old PC > that is connected to the network. The digital library community seem > particularly sensitive to these issues, which is perhaps why they use > handles, DOIs, and ARK. > > Regards > > Rod > > > > ------------------------------------------------------------------------ > ---------------------------------------- > 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 > 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 at http://darwin.zoology.gla.ac.uk/~rpage/portal/ > Find out what we know about a species at http://ispecies.org > > > > > > > ___________________________________________________________ > Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with > voicemail http://uk.messenger.yahoo.com >

1 0