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

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

30 Jan '06

It would appear to me that we need something built into the Metadata of the GUID to link objects that are essentially the same (but in fact always slightly different) Example: Chapman 541 is a collecting event off one tree with duplicate specimens sent to Kew and Canberra. If each gets a GUID and we are going to use GUIDs to identify the 'synonymy' of collection then the only way would be for guid1234 be the collecting event and guid1234-1, guid1234-2 or something similar would indicate that they were (in way) children of the collecting event guid1234. There is always need to identify the Kew collection and the Canberra collection separately for a whole number of reasons, but there is also a need to identify them as the same collecting event. The second way of doing it is to design a strict metadata standard that is attached to the GUID (a TDWG task I guess). One key (repeatable) field in that metadata would then be along the lines of "related_guids" and "relationship_type". We would of couse then need to come up with an ontology of relationship types. Using the metadata may be the cleanest (and in the long run easiest and most practical) way of handling the relationship between guids. It also allows for the later creation of a new guid related to the first where, for example, genetic material, pollen samples, etc. may be taken from one of the specimens. It is also a simple way of linking the offspring of an object, etc. Good luck with the meeting - I look forward to the outcomes. Cheers Arthur Chapman Australian Biodiversity Information Services Toowoomba, Australia >>>From Roderic Page <r.page(a)BIO.GLA.AC.UK> on 30 Jan 2006: > > > > We need to decide under which circumstances we want this to be a > > bidirectional implication, i.e. that: > > > > B) O1 == O2 --> I1 == I2 > > > > My 30 second reaction to this is that it assumes that the metadata > attached to I1 and I2 are the same, which may often not be the case. > For example, a paper may have several GUIDs attached to it, it is in > some sense the same object, but PubMed offers different metadata to > CrossRef (links to sequences, MeSH keywords, etc., versus strictly > bibliographic data), which is different to Google Scholar (links to > papers that cite the work), different to handles in DSpace repositories > (GUID for a freely available copy), and so on. > > Can we not, at least initially, have a mapping between GUIDs, and then > if somebody wants to take on the task of generating single GUIDs for a > set of related GUIDs, then they can undertake that? I suspect that, > realistically, such an undertaking would only be feasible (and indeed, > useful) if we first have GUIDs for the existing databases in place. > > Yes, a plethora of ids can be a pain (just look at the situation in > bioinformatics) -- that said, the abundance of identifiers in > bioinformatics reflects the desire of people to add value to existing > databases. > > So long as we can infer that I1 and I2 are both talking about O1, why > force I1==I2, when metadata(I1) and metadata(I2) may be different, and > both have value. > > I think we need to separate two goals: having unique, resolvable > identifiers for existing objects, and sorting out the issue of > multiple, possibly conflicting identifiers and metadata for the "same" > object. One is easier, one is harder, but I think the hard one needs > the easy one to be solved first. > > But then I'm probably simply being both naive and impatient, which is > not a good combination. > > 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 >

1 0

Re: How GUIDs will be used
by Donald Hobern 30 Jan '06

30 Jan '06

I certainly agree that collaborative assignment of identifier is one of the most critical issues we need to address in our discussions. Here are some of my thoughts attempting to approach the problem. If identifier I1 refers to data object O1 and identifier I2 refers to data object O2, our minimal requirement for GUIDs would be that: A) I1 == I2 --> O1 == O2 (for all relevant purposes) We need to decide under which circumstances we want this to be a bidirectional implication, i.e. that: B) O1 == O2 --> I1 == I2 I believe that we will need to address this question separately for different classes of data. We need to relate the objects we identify to clearly defined data classes. If a nomenclatural GUID is actually the identifier for a record in a nomenclatural database rather than for the associated nomenclatural event, we may not have to worry about getting IPNI and MOBOT to use the same identifier for their records. The possible downside is that such an approach is an unambitious one that only solves a subset of our problems. We should consider what it would take for us to devise a system that could support (enforce?) bidirectional inference in those cases in which it matters to us. It seems pretty clear to me that such a system would operate by layering further standards and best practices on top of the actual identifier system. In general we need to think hard about management of GUIDs for each data class. I suggest that the goal of these workshops is to allow us to select a framework of identifiers that will meet our needs, but that TDWG and others should then develop applicability statements which define exactly how we expect to use them in different contexts. These statements would in each case also make explicit the semantic and operational characteristics that a provider is expected to support. Donald --------------------------------------------------------------- Donald Hobern (dhobern(a)gbif.org) Programme Officer for Data Access and Database Interoperability Global Biodiversity Information Facility Secretariat Universitetsparken 15, DK-2100 Copenhagen, Denmark Tel: +45-35321483 Mobile: +45-28751483 Fax: +45-35321480 --------------------------------------------------------------- -----Original Message----- From: Taxonomic Databases Working Group GUID Project [mailto:TDWG-GUID@LISTSERV.NHM.KU.EDU] On Behalf Of Roderic Page Sent: 30 January 2006 13:37 To: TDWG-GUID(a)LISTSERV.NHM.KU.EDU Subject: Re: How GUIDs will be used 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 (and yes, we DO need GUIDs for names). 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. 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? 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. 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". Ducks incoming flames/brickbats/etc. Regards Rod On 30 Jan 2006, at 11:59, Richard Pyle wrote: > 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 > > ------------------------------------------------------------------------ ---------------------------------------- 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

1 0

Re: How GUIDs will be used
by Roderic Page 30 Jan '06

30 Jan '06

> > We need to decide under which circumstances we want this to be a > bidirectional implication, i.e. that: > > B) O1 == O2 --> I1 == I2 > My 30 second reaction to this is that it assumes that the metadata attached to I1 and I2 are the same, which may often not be the case. For example, a paper may have several GUIDs attached to it, it is in some sense the same object, but PubMed offers different metadata to CrossRef (links to sequences, MeSH keywords, etc., versus strictly bibliographic data), which is different to Google Scholar (links to papers that cite the work), different to handles in DSpace repositories (GUID for a freely available copy), and so on. Can we not, at least initially, have a mapping between GUIDs, and then if somebody wants to take on the task of generating single GUIDs for a set of related GUIDs, then they can undertake that? I suspect that, realistically, such an undertaking would only be feasible (and indeed, useful) if we first have GUIDs for the existing databases in place. Yes, a plethora of ids can be a pain (just look at the situation in bioinformatics) -- that said, the abundance of identifiers in bioinformatics reflects the desire of people to add value to existing databases. So long as we can infer that I1 and I2 are both talking about O1, why force I1==I2, when metadata(I1) and metadata(I2) may be different, and both have value. I think we need to separate two goals: having unique, resolvable identifiers for existing objects, and sorting out the issue of multiple, possibly conflicting identifiers and metadata for the "same" object. One is easier, one is harder, but I think the hard one needs the easy one to be solved first. But then I'm probably simply being both naive and impatient, which is not a good combination. 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

1 0

Re: How GUIDs will be used
by Roderic Page 30 Jan '06

30 Jan '06

On 30 Jan 2006, at 13:41, Sally Hinchcliffe wrote: > Hi all, > having started this hare ... > >> 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 (and yes, we DO need GUIDs for names). >> > Well I think one of the consensus positions we were converging on was > that nomenclators who issue ids (IPNI, IF) could continue to do so, > and that those ids, suitably qualified would form the basis of a guid > system for names. Whether these would be the _sole_ id for that name > or whether some other rival nomenclator might spring up issuing its > own ids (and if somebody wants to do plants let me know!!) was not > really settled Maybe I've been influenced too much by Google, but more and more I think that in order to scale up to the task in hand we need to break things into bite size bits, automate as much as possible, and avoid manual intervention if we can (i.e., use it sparingly where it matters -- expertise is rare and expensive). Likewise, I suspect attempts to settle on sole ids from on hi will not be productive. Rather, if a nomenclature offers a good service then people will use it. > >> 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. >> >> 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? 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. >> > Curiously enough, in answer to your first rhetorical question, IPNI & > MOBOT _ARE_ going to map up our ids for entirely other reasons. We > are staring into the black hole of this particular task and I know > that when we have done so the fact 'IPNI id 12345-1' is the same > names as 'TROPICOS 34509' will be a hard won and expensive fact and > we aren't going to want to lose it. > Nor should you have to. IPNI can include in the metadata it serves for IPNI id 12345-1 that it is the same as TROPICOS 34509 (and visa versa). In the same way, in the LSIDs I server I include mappings between databases where possible (e.g., uBio records linked to ITIS, NCBI linked to ITIS, MOBOT, and TreeBASE). >> 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 do think the GUIDs for names should be resolvable, and as soon as > an agreed technology is selected I'll be putting in place plans to > have IPNI to implement it. What I'm saying is that that is (to some > users) secondary to being able to state facts like the one above - x > is the same as y - in a stable way without having to go down the long > road of fuzzy string matching, different author abbreviations, latin > gender endings etc etc. Everybody has different needs, and resources are limited. To me one appeal of GUIDs is that I can have a list of them (say, 10,000) and fire them off to a GUID resolver, and get back all the info I need (for example, I could dump the metadata straight into a database and do some work). If IPNI has mappings to MOBOT, then with the MOBOT GUIDs I can extract what I need from them. Going to a web site and doing it manually is agony. Of course, for a few cases a web site is the way to do it. > >> I'm probably being wildly naive, but I think concern for getting it >> "right" might get in the way of getting it "done". >> >> Ducks incoming flames/brickbats/etc. >> > not from me ... looking forward to discussing this one in person in a > couple of days > Sally *** Sally Hinchcliffe > *** Computer section, Royal Botanic Gardens, Kew > *** tel: +44 (0)20 8332 5708 > *** S.Hinchcliffe(a)rbgkew.org.uk > > ------------------------------------------------------------------------ ---------------------------------------- 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

1 0

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

30 Jan '06

Arthur 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. > 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? 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 Sally Hinchcliffe 30 Jan '06

30 Jan '06

Hi all, having started this hare ... > 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 (and yes, we DO need GUIDs for names). > Well I think one of the consensus positions we were converging on was that nomenclators who issue ids (IPNI, IF) could continue to do so, and that those ids, suitably qualified would form the basis of a guid system for names. Whether these would be the _sole_ id for that name or whether some other rival nomenclator might spring up issuing its own ids (and if somebody wants to do plants let me know!!) was not really settled > 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. > > 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? 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. > Curiously enough, in answer to your first rhetorical question, IPNI & MOBOT _ARE_ going to map up our ids for entirely other reasons. We are staring into the black hole of this particular task and I know that when we have done so the fact 'IPNI id 12345-1' is the same names as 'TROPICOS 34509' will be a hard won and expensive fact and we aren't going to want to lose it. > 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 do think the GUIDs for names should be resolvable, and as soon as an agreed technology is selected I'll be putting in place plans to have IPNI to implement it. What I'm saying is that that is (to some users) secondary to being able to state facts like the one above - x is the same as y - in a stable way without having to go down the long road of fuzzy string matching, different author abbreviations, latin gender endings etc etc. > I'm probably being wildly naive, but I think concern for getting it > "right" might get in the way of getting it "done". > > Ducks incoming flames/brickbats/etc. > not from me ... looking forward to discussing this one in person in a couple of days 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 [ Scanned for viruses ]
by Paul Kirk 30 Jan '06

30 Jan '06

Some things happen from the top down - NOMENCLATURE - and thank god they do otherwise the chaos of (some) taxonomy would be increased by orders of magnitude ... or am I being naive? Paul Dr Paul M. Kirk Biosystematist CABI Bioscience Bakeham Lane Egham Surrey TW20 9TY UK tel. (+44) (0)1491 829023, fax (+44) (0)1491 829100, email p.kirk(a)cabi.org www.cabi-bioscience.org *********************************************************************** 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 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. *********************************************************************** -----Original Message----- From: Taxonomic Databases Working Group GUID Project [mailto:TDWG-GUID@LISTSERV.NHM.KU.EDU]On Behalf Of Roderic Page Sent: 30 January 2006 13:25 To: TDWG-GUID(a)LISTSERV.NHM.KU.EDU Subject: Re: How GUIDs will be used [ Scanned for viruses ] A few quick thoughts. On 30 Jan 2006, at 13:12, 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. > > 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. But names are not unique (Agathis montana is a wasp and a tree), not stable, there is no way to resolve them, and most of the metadata is locked up in dead trees (journals), much of it under copyright. > > 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. > The issue of centralisation and "taxonomic freedom" is a red herring (due to Rich and I talking past each other -- my fault). 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. My sense is that things happen from the ground up, not the other way around. Put another way, there is nothing technically stopping any database setting up GUIDs today -- so what is stopping us (and yes, I'm being a little facetious). Regards Rod > 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 >> > > ------------------------------------------------------------------------ ---------------------------------------- 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

1 0

Re: How GUIDs will be used
by Roderic Page 30 Jan '06

30 Jan '06

A few quick thoughts. On 30 Jan 2006, at 13:12, 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. > > 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. But names are not unique (Agathis montana is a wasp and a tree), not stable, there is no way to resolve them, and most of the metadata is locked up in dead trees (journals), much of it under copyright. > > 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. > The issue of centralisation and "taxonomic freedom" is a red herring (due to Rich and I talking past each other -- my fault). 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. My sense is that things happen from the ground up, not the other way around. Put another way, there is nothing technically stopping any database setting up GUIDs today -- so what is stopping us (and yes, I'm being a little facetious). Regards Rod > 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 >> > > ------------------------------------------------------------------------ ---------------------------------------- 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

1 0

Re: How GUIDs will be used
by Roderic Page 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 (and yes, we DO need GUIDs for names). 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. 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? 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. 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". Ducks incoming flames/brickbats/etc. Regards Rod On 30 Jan 2006, at 11:59, Richard Pyle wrote: > 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 > > ------------------------------------------------------------------------ ---------------------------------------- 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

1 0

Re: How GUIDs will be used
by Roderic Page 30 Jan '06

30 Jan '06

> > 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. > 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. 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? 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. 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. Regards Rod > 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 > > ------------------------------------------------------------------------ ---------------------------------------- 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

1 0