November 2005 - tdwg-tag - lists.tdwg.org

Re: simple explanation of a taxon concept
by Richard Pyle 04 Nov '05

04 Nov '05

Hi Sally, I don't know of any simple definitions on the web, but here's my simple definition: A defined or implied set of organisms. Aloha, Rich > -----Original Message----- > From: Taxonomic Databases Working Group GUID Project > [mailto:TDWG-GUID@LISTSERV.NHM.KU.EDU]On Behalf Of Sally Hinchcliffe > Sent: Friday, November 04, 2005 6:26 AM > To: TDWG-GUID(a)LISTSERV.NHM.KU.EDU > Subject: simple explanation of a taxon concept > > > Hi all, > can any of you people point me towards a web resource where one of > our data managers (specialising in economic botany) can have this > question answered: > > I must admit I'm not altogether sure what is meant by the term taxon > "concepts" (is there a simple explanation?) > > I'm circulating Donald's questions around the various Kew staff who > are involved in databases and some of them for some reason don't seem > to have kept up with the recent fevered debate on TCS-LC and other > fora > > Thanks > *** Sally Hinchcliffe > *** Computer section, Royal Botanic Gardens, Kew > *** tel: +44 (0)20 8332 5708 > *** S.Hinchcliffe(a)rbgkew.org.uk

1 0

Re: Topic 3: GUIDs for Taxon Names and Taxon Concepts
by Sally Hinchcliffe 04 Nov '05

04 Nov '05

Rod Page wrote: > Perhaps to try and clarify my previous post (not a good idea to write > before the coffee has kicked in), as a straw man what's wrong with the > following approach: > > 1. Data providers serve up their own records, each identified by a GUID > Agree, although for some areas there might be some control over _who_ is a data provider to prevent overlap? > 2. At a minimum a "record" is metadata about that object, using > existing vocabulary as much as possible. This means Dublin Core for > basic stuff (title, creator, etc.), Prism for bibliographic details, > Basic Geo (WGS84 for geographic co-ordinates, Darwin Core for other > specimen stuff, etc. > > 3. Such records may refer to other objects (e.g., a sequence may refer > to a publication and a museum voucher specimen), all by way of GUIDs. > > 4. Each record carries a Creative Commons license specifying what you > can do with the data. The present system where museums have some text > saying what can and can't be done is too clumsy, and putting the GBIF > data usage agreement in the way of searching GBIF is way too > cumbersome. > > If we do this (and we're pretty close to this already), then I think > we've got the core of a useful resource. Partly because all of this is > technically easy to do, and is already being done in other areas. So, > why not just do it? > > ---- > > I think the role of GUIDs is to (a) unambiguously identify digital > objects, and (b) tell us where to get that digital record. > > Many of the issues that crop up here are, in my opinion, not really > about GUIDs. Regarding the issue of taxonomic concepts, I think this is > something of a red herring. If concepts are essentially a pairing of > name and use, then given a GUID for a name and a publication, there > will be huge numbers of these, and they will occur in all sorts of > domains (taxonomy, ecology, development, conservation, medicine, etc.). > They will also exist in databases (e.g., GenBank, TreeBASE, etc.). But > if they are pairings of names and usage (e.g., publication, database), > then given a name GUID and a usage GUID, do we need anything else, > really? Names, publications, and specimens are primary, concepts are > secondary. > Interesting - you could end up with a sort of hashed or concatenated guid (because people don't like dealing with composite keys). This might help with specimens which are duplicates of other specimens from the same collecting event - no need to unambiguously ID the event itself centrally if you can ID the collector and the ID he/she gave it ... although IDs for Collectors seems like it will be a long way off. > It seems to me the core notion of a concept is knowing what somebody > meant when using a name. This is (a) a problem of inference, and (b) > probably intractable in most cases (who knows what ecologist "x" meant > by species "y" in 1910, regardless of what classification he or she may > have claimed to be using). > > One example where this inference is more straightforward, especially > given 1-4 above, is if observations are linked to specimens. For > example, in TreeBASE there are various occurrences of "Apomys datae" in > different studies. Given that these names are linked to sequences, > which are linked to specimens, we can infer that these different > occurrences are the same thing. This kind of inference is made much > easier when data is openly available. I also think that inference of > concepts will be domain-specific, localised to particular questions, > and not necessarily something taxonomic databases need to themselves > support. Do we seriously think we can build a database of the usage of > all names and what they meant? I suggest this knowledge will emerge > over time on the foundations of 1-4 above. Since taxonomists don't > control how names are used, and probably use names a lot less than > other biologists (after all, we provide names so biologists can > communicate), I don't think it is the role of taxonomists to document > every concept. > > The KISS principle (Keep It Simple Stupid) would seem to apply here. > Why not focus on something that is achievable, has value, and can be > linked to what people in other areas are doing (such as bioinformatics, > the Semantic Web, etc.). > > In other words, maybe it's time to stop thinking like taxonomists... > > > ------------------------------------------------------------------------ > ---------------------------------------- > 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 > > > > > ___________________________________________________________ > To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com *** Sally Hinchcliffe *** Computer section, Royal Botanic Gardens, Kew *** tel: +44 (0)20 8332 5708 *** S.Hinchcliffe(a)rbgkew.org.uk

1 0

Re: Topic 3: GUIDs for Taxon Names and Taxon Concepts
by Roderic Page 04 Nov '05

04 Nov '05

Perhaps to try and clarify my previous post (not a good idea to write before the coffee has kicked in), as a straw man what's wrong with the following approach: 1. Data providers serve up their own records, each identified by a GUID 2. At a minimum a "record" is metadata about that object, using existing vocabulary as much as possible. This means Dublin Core for basic stuff (title, creator, etc.), Prism for bibliographic details, Basic Geo (WGS84 for geographic co-ordinates, Darwin Core for other specimen stuff, etc. 3. Such records may refer to other objects (e.g., a sequence may refer to a publication and a museum voucher specimen), all by way of GUIDs. 4. Each record carries a Creative Commons license specifying what you can do with the data. The present system where museums have some text saying what can and can't be done is too clumsy, and putting the GBIF data usage agreement in the way of searching GBIF is way too cumbersome. If we do this (and we're pretty close to this already), then I think we've got the core of a useful resource. Partly because all of this is technically easy to do, and is already being done in other areas. So, why not just do it? ---- I think the role of GUIDs is to (a) unambiguously identify digital objects, and (b) tell us where to get that digital record. Many of the issues that crop up here are, in my opinion, not really about GUIDs. Regarding the issue of taxonomic concepts, I think this is something of a red herring. If concepts are essentially a pairing of name and use, then given a GUID for a name and a publication, there will be huge numbers of these, and they will occur in all sorts of domains (taxonomy, ecology, development, conservation, medicine, etc.). They will also exist in databases (e.g., GenBank, TreeBASE, etc.). But if they are pairings of names and usage (e.g., publication, database), then given a name GUID and a usage GUID, do we need anything else, really? Names, publications, and specimens are primary, concepts are secondary. It seems to me the core notion of a concept is knowing what somebody meant when using a name. This is (a) a problem of inference, and (b) probably intractable in most cases (who knows what ecologist "x" meant by species "y" in 1910, regardless of what classification he or she may have claimed to be using). One example where this inference is more straightforward, especially given 1-4 above, is if observations are linked to specimens. For example, in TreeBASE there are various occurrences of "Apomys datae" in different studies. Given that these names are linked to sequences, which are linked to specimens, we can infer that these different occurrences are the same thing. This kind of inference is made much easier when data is openly available. I also think that inference of concepts will be domain-specific, localised to particular questions, and not necessarily something taxonomic databases need to themselves support. Do we seriously think we can build a database of the usage of all names and what they meant? I suggest this knowledge will emerge over time on the foundations of 1-4 above. Since taxonomists don't control how names are used, and probably use names a lot less than other biologists (after all, we provide names so biologists can communicate), I don't think it is the role of taxonomists to document every concept. The KISS principle (Keep It Simple Stupid) would seem to apply here. Why not focus on something that is achievable, has value, and can be linked to what people in other areas are doing (such as bioinformatics, the Semantic Web, etc.). In other words, maybe it's time to stop thinking like taxonomists... ------------------------------------------------------------------------ ---------------------------------------- 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 ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com

1 0

Re: [tdwg-tapir] Tapir > Capabilities > Schemas > Concepts
by "Döring, Markus" 04 Nov '05

04 Nov '05

Steven, in principal I see the same problems with atomic concepts as you described. The idea of TAPIR was to deal only with atomic concepts, but allow other software to be aware of a concepts meaning. So the vision is to move away from xpath-style concept ids to ids used in "ontologies" at some time. Still the protocol request itself doesnt know how measurement and unit are related, but an external knowledge could provide this - and the simple atomic concept ID would be the key into the ontology. So a wrapper receiving this kind of request could understand the relation and transform the values! It would probably not make much sense to allow searches on calculated values, but for additional result generation this would be fine. Also the current PyWrapper does deal with multiple mappings for a single concepts for example. Its not just 1 XML element = 1 column. A single mapping again can be a concatenation of columns or fixed strings. But surely these are just the most common and simple data transformations. But I dont see that the protocol stops you from creating more sophisticated ones. Markus -----Ursprüngliche Nachricht----- Von: tdwg-tapir-bounces(a)lists.tdwg.org [mailto:tdwg-tapir-bounces@lists.tdwg.org] Im Auftrag von Steven Perry Gesendet: Donnerstag, 3. November 2005 16:48 An: tdwg-tapir(a)lists.tdwg.org Betreff: Re: [tdwg-tapir] Tapir > Capabilities > Schemas > Concepts Hi Roger, I'm not a PyWrapper developer, so my opinion is certainly not authoritative, but my understanding is that PyWrapper only maps concepts that correspond to attributes or leaf XML elements (those elements that contain only text node children and do not contain other elements). In other words, CanonicalName is not considered by PyWrapper to be a concept. Neither is TaxonNames, TaxonName, or DataSet. The concept mapping system in PyWrapper allows only a direct correspondence between a database column (or literal or concatenation of a combination of literals and columns) and an "atomic" XML element (or attribute). My understanding is that the goal that lead to this design decision was that one would want to query an abstract data model, and not an XML document. This abstract data model is equivalent to a list of hashtables that contains concept = value pairs. In my opinion this approach has both advantages and disadvantages. On the one hand, using an abstract data model makes it possible to do views, which is considered a huge advantage. On the other hand this definition of concept (essentially 1 XML element = 1 column) means that the abstract data model is limited to a simple hashtable. This is like programming without data structures, like C with no structs or Java with no classes or objects, and is therefore somewhat limiting. Another disadvantage is that this data model assumes that concepts are completely context-free. In other words, no concept can depend upon another to set the context for it's semantic meaning. This is difficult to handle if you have a schema that allows a chunk of XML like the following: <depth> <measurement>112</measurement> <unit>fathoms</unit> </depth> In this example, what we're really concerned with is the concept of depth (which cannot be expressed in PyWrapper/TAPIR). Depth's full semantic meaning is dependent upon both measurement and unit. If one substitutes measurement for depth (as you would do with PyWrapper), then depth/measurement is contextually constrained by the meaning of the independent concept depth/unit. However there is no way within the concept mapping or view system to relate these two concepts automatically, so it's up to the developer of a particular view to understand the relationship between these concepts and to treat is appropriately. The problem is one can't even treat it properly for some view schema using the view subsystem. The issue here is that PyWrapper cannot do transformation on concept values. So, if you wanted to map the above version of a depth concept into a Darwin Core MaNIS depth concept using PyWrapper, you can do one of two things. You could Forgo translation and map depth/unit directly into dwc:DepthInMeters (which would be wrong because 112 fathoms != 112 meters) or you could set dwc:DepthInMeters to the concatenation of depth/measurement and depth/unit, in this case forming the string "112 fathoms" (which is also wrong because this is not a "depth in meters" and would prevent the generated Darwin Core instance from validating). The only proper way to handle this case with PyWrapper is to foresee that your user will want to use a Darwin Core view, and to create a new column in your underlying database that contains depth in meters, then map this concept into PyWrapper. In essence, this bypasses the view subsystem and relies on concept mapping and your own translation program that exists outside of PyWrapper to do the job properly. This is a general problem shared by all designs that use independent atomic concepts. Please don't think I'm denigrating PyWrapper. The problem of searching an arbitrary database structure and mapping the results into an arbitrary XML schema instance is difficult enough without having to worry about mapping non-atomic concepts. I just wanted to point out that using atomic concepts has some serious limitations. -Steve Roger Hyam wrote: > I am a little confused as to what is included in the capabilities > response under capabilities/schemas/schema. > > The annotation says: > > "Each known and mapped concept of a schema listed with a boolean flag > indicating if its searchable (default = true)." > > I have a genus field in my database and I map it to the following concept: > > <concept path="/DataSet/TaxonNames/TaxonName/CanonicalName/Genus" > searchable="true" /> > > Should I also include the parent concepts: > > <concept path="/DataSet/TaxonNames/TaxonName/CanonicalName" > searchable="false" /> > <concept path="/DataSet/TaxonNames/TaxonName" searchable="false" /> > <concept path="/DataSet/TaxonNames" searchable="false" /> <concept > path="/DataSet" searchable="false" /> > > or are they implied? I presume if they are included then they aren't > searchable as they can't be used to build filters. > > Does this: > > <concept path="/DataSet/TaxonNames/TaxonName/CanonicalName/Genus" > searchable="true" /> > > mean: > > * This concept has been mapped to data and can be used in > arbitrary response structures and filters in combination with > concepts from any of the other conceptual schemas listed in here. > > If so is the entire schemas section of capabilities response optional > if arbitrary views are not supported? Both the schemas and concepts > are given in views anyhow - so do we need to list them here? > > Your thoughts most appreciated - I may just have the wrong end of the > stick. > > Roger > > > >-- > >------------------------------------- > Roger Hyam > Technical Architect > Taxonomic Databases Working Group >------------------------------------- > http://www.tdwg.org > roger(a)tdwg.org > +44 1578 722782 >------------------------------------- > > > >----------------------------------------------------------------------- >- > >_______________________________________________ >tdwg-tapir mailing list >tdwg-tapir(a)lists.tdwg.org >http://lists.tdwg.org/mailman/listinfo/tdwg-tapir_lists.tdwg.org > > _______________________________________________ tdwg-tapir mailing list tdwg-tapir(a)lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tapir_lists.tdwg.org

1 0

Re: Topic 3: GUIDs for Taxon Names and Taxon Concepts
by Sally Hinchcliffe 04 Nov '05

04 Nov '05

Rich wrote (in response to Yde) > > For practical reasons I think the starting point for assigning > > GUIDs should be basically nomenclatural. > > I completely agree -- but again, what gets a "Name" GUID? (as opposed to a > "usage" GUID or a "concept" GUID) Only basionyms? (I hope!) Or also > different combinations? (I hope not!) Or also spelling variants? (I *really* > hope not!!) There is also a problem of how to deal with autonyms > (=nominotypical names in zoology). One GUID, or two? Logically, only one -- > but most people don't do it that way. > I agree that name guids are probably a good place to start, partly because they're one of the areas where the rules have been fairly thoroughly thrashed out over the past 200 years ... I would argue (after all the debate that went on in the TCS-LC mailing list) that a new combination _should_ get a GUID, (after all, as has been said before, GUIDs are cheap...) because there is a good mechanism in the LC part of the TCS to resolve from a new combination to the base name. However if the zoologists don't like to treat new combinations as names in their own right, I see no problem with them not doing it ... as long as whatever system we come up with will allow both approaches side by side. I would also agree with Rod Page that GUIDs don't need to be centrally administered (which helps with the fact that different kingdoms have different rules for what constitutes a name). I admit I might be a bit biased here, but it seems to me that where there are nomenclators that are widely used then they should issue the GUIDs (and even if they don't their ids may well become de facto guids). As long as everyone agrees that, say, for Fungi, IF ids are the guids and as long as IF doesn't do anything like change their ids or delete records, then I can't see the need for any central repository replicating what IF does. GUIIDs for names should probably end up being a combination of something pointing to the nomenclator, and then the nomenclator's own id. If nomenclators aren't complete or aren't fully digitised then surely resources would be better spent on the 20% of effort of making the nomenclator better, rather than the 100% of effort of creating what would be a global nomenclator from scratch. Obviously the zoologists have always had the problem that they don't have a comprehensive nomenclator but now that they're working on that with registration - are there any other significant gaps that aren't covered by a nomenclator of some sort that could be used to issue ids? Problem solved? ;-) *** Sally Hinchcliffe *** Computer section, Royal Botanic Gardens, Kew *** tel: +44 (0)20 8332 5708 *** S.Hinchcliffe(a)rbgkew.org.uk

1 0

Re: Topic 3: GUIDs for Taxon Names and Taxon Concepts
by Roderic Page 04 Nov '05

04 Nov '05

I'm a bit concerned that some may have conflated "Global" with "Centralised". GUIDs do not need to be centrally issued, indeed I'd argue that this is counter productive. To my mind the lesson from the web is decentralisation is the only way to cope with the issue of scale. Attempts at grandiose centralisation tend to fail. Hence, we should plan for GUIDs to be issued by more than one data source. After all, we are talking about GUIDs for digital objects, not ideas. The idea that only the resolution system needs to be able to distinguish between specimens, taxon names, etc., seems unfortunate. With LSIDs the GUID has a namespace element, which can be readily used to distinguish between types of record (e.g., a PubMed record and a DNA sequence record from NCBI have different namespaces). Assigning GUIDs solely to basionyms strikes me as crazy -- I'd suggest most taxa aren't known by their basionyms. I'd advocate GUIDs for every name string (with the possible exception of orthographic variants, spelling mistakes, etc.). I don't really think this is about taxonomy, it's about information retrieval and stability of identifiers for digital objects. Lastly, "imposing standards" is the wrong way to think about this. Standards win support if they work, and are adopted. I'd suggest this stuff will happen if people make compelling applications that others make use of, not because TDWG decides what should be done. So, my final question is, what is wrong with having each taxonomic database serve their own GUIDs for their own data (using an agreed format, such as RDF), and where possible GUIDs from different sources are mapped (e.g., a name string in IPNI to one in uBio). Users employ whatever GUID they find useful -- at least we then know what digital object they are referring to. If we think of the scientific literature, many paper have at least two GUIDs (DOI and PubMed), both of which are useful, and which serve different purposes. This may seem like a recipe for anarchy, but we can do this now (and, in effect we already have, my Taxonomic Search Engine serves LSIDs for the major taxonomic name databases). If we think the solution rests with a central authority (and ZooBank) then I think we are fooling ourselves. 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: Topic 3: GUIDs for Taxon Names and Taxon Concepts - Maybe ...
by Richard Pyle 03 Nov '05

03 Nov '05

Thanks, Jessie. No doubt I am the culprit for many misunderstandings -- especially given that is is nearly 4am and I should really call it quits. > I agree with Donald that a shorthand to referring to a Taxon_Concept is the combination > of Taxon_Name and the Taxon_Publication. This is slightly but importantly different to > Rich here in that the publication should be seen as a taxonomic publication (for > another discussion elsewhere) rather than any publication - i.e. not simply usage of a > name which could include an observation or identification - this interpretation > opens up Taxonomic_Concepts too widely to cover potential taxa rather than those which > have been defined, described and published in some scientific manner.) In the context of this discussion, I'm not quibbling on this point. I'm happy to assume, for the moment, that "Concepts" would be a (small) subset of usages. I didn't mean to draw this distinction, and I apologize if it seems like I did. I've only used the term "usage" in the sense of "SEC" -- I did not mean to insinuate that *all* usages should be thought of as concepts. Like you said -- for another discussion elsewhere. > I agree with Sally that we should have Nomenclators provide GUIDs for Taxon_Names but > would be more strict and say that these names should have only one GUID and that the GUID > should always resolve to exactly the same name. So IPNI would be plant names, Index > fugorum fungi names, zoobank when available animal names etc. and that we should > share the resource of fixing this rather than duplicating effort (if I had any > resource to give;-) ) IPNI and IF wouldn't overlap in names. This is congruent with my thinking. But are you comfortable with these different nomenclators having different definitions of a "name"? Might make it hard to pool cross-nomenclator data. Definitely bed time... Rich

1 0

Re: Two kinds of GUIDs?
by Richard Pyle 03 Nov '05

03 Nov '05

Yde, I fully agree with everything in your post (below), with the caveat that the process of cross-mapping will be DRAMATICALLY more straightforward if we address the 'what's in the name' issue early. Aloha, Rich > -----Original Message----- > From: Taxonomic Databases Working Group GUID Project > [mailto:TDWG-GUID@LISTSERV.NHM.KU.EDU]On Behalf Of Yde de Jong > Sent: Friday, November 04, 2005 12:56 AM > To: TDWG-GUID(a)LISTSERV.NHM.KU.EDU > Subject: Two kinds of GUIDs? > > > Dear all, > > Considering the last messages. > > In my understanding (sorry for repeating part of your input) we can > distinguish two kinds of GUIDs: > > (1) Universal GUIDs like the ISBN numbers of publications and the > GeneBank codes of sequences. > > (2) Local GUIDs, which are uniquely linked to objects in your (local) > database, however, which metadata and metadata structure is > standardised (in our case by GBIF). > > The Universal GUIDs we need for unambiguous cross-linking of > databases, because we can't match databases efficiently otherwise > (e.g. semantically). Indeed in the future everyone should add a > column to its taxon table and cross-reference to a universal GUIDs > system (=nomenclator) which keep the standard GUIDs for each name > (let's leave 'what's in the name' for the moment). > > For me its clear that there is a difference between the use of a name > within a concept and the name itself. Such a universal GUIDs system > doesn't need to deal with the use of names and therefore not with > concepts. Actually names within a nomenclator should never change, > only the content should grow through time (like sequence data in > GeneBank). > > Local GUIDs are important for GBIF to show the origin of data. This > is essential not only for a proper acknowledgement, but also to > identify possible duplications (e.g. Fauna Europaea data sets are > being implemented in many other databases, GBIF needs to have a tool > to detect such duplications). > > In addition those local GUIDs can be used, when cross-mapped with > universal GUIDs, to provide concepts for the GBIF portal in a > workable way. Meaning that a GBIF portal user can chose which species > concept (e.g. that of the CoL) he/she would like to use for > connecting the requested biodiversity data. > > Kind regards, > > Yde

1 0

Re: Topic 3: GUIDs for Taxon Names and Taxon Concepts
by Richard Pyle 03 Nov '05

03 Nov '05

> > By "Namestring", do you include author, our just taxonomic > > nomenclatural > > elements? In either case, why even bother establishing a GUID for > > taxonomic > > names at all? Why not just use the namestring itself? > > Oh come on, you can't be serious ;-) Names aren't unique, GUIDs are. You didn't answer my question: By "Namestring", do you include author, our just taxonomic nomenclatural elements? If you do not include author details (as I suspect from your comment above), then you are right: namestrings are non-unique because of homonyms. If you do include author elements, then namestrings can approach uniqueness. So, let me ask you a seemingly simple question: If you feel that any namestring (with the possible exception of orthographic variants) should receive a GUID, then does the GUID represent the namestring per se? Or, does it represent the name "object" (with implied secondary data such as authorship, type specimen, etc.)? If the namestring per se, then again I ask why do we need GUIDs at all? If the answer is "to disambiguate homonyms", then it seems the GUID represents the abstract name "object", rather than the sequence of text characters. So, if a "Name GUID" is intended to represent a name "object", then what is the definition and scope of such objects that would be candidates for GUIDs? All names? Scientific names only? What sort of attributes would these name objects have? > > Moreover, I don't think anyone has suggest that GUIDs be assigned > > "solely" > > to basionyms. > > Er, I quote from your earlier post. > > > I completely agree -- but again, what gets a "Name" GUID? (as opposed > to a > > "usage" GUID or a "concept" GUID) Only basionyms? (I hope!) Or also > > different combinations? (I hope not!) Or also spelling variants? (I > *really* > > hope not!!) I'll say it again: I don't think anyone has suggest that GUIDs be assigned "solely" to basionyms. As you said yourself: "The idea that only the resolution system needs to be able to distinguish between specimens, taxon names, etc., seems unfortunate." If I understand this sentence correctly, you are saying that it's important to think of distinct "domains" of GUIDs. For example, publications are a different domain from specimens, and taxon names are a different domain still. Please note in my quote above my qualification of "Name" GUID. I was talking about GUIDs within the Taxon name "domain" only. To say that I hope that "Name" GUIDs are only applied to basionyms is *NOT* the same as saying that non-basionyms should not have *any* GUID -- just that I don't think that non-basionyms fall within the scope of what I believe should be treated as a name-object (i.e., candidate for a "Name GUID"). Stated another way, if you dissect the informational components of nomenclature, basionyms represent a (mostly) unambiguous and (mostly) objectively-definable unit object. Nomenclature beyond basionyms (combinations, orthographic variants, etc.) *can* be thought of as additional instances of name objects, but they can *also* be thought of as attributes of name usage instances (a different domain from name objects). My preference is the latter (not because I'm a zoologist, but because I see it as more reflective of how nomenclatural information is really structured). > For me the point is that if you have a GUID, I can map to you and add > value to my projects. Without a GUID, it's a pain. But if the units to which we assign GUIDs are non-comparable, how can we cross-map them (without it being a pain)? > If it hurts don't do it! Put another way, why not make the mapping > purely nomenclatural -- this name string also occurs in ITIS, and don't > make any claims that whatever ITIS means by that name is what you mean. I can do that just fine without GUIDs. My hope is that GUIDs will enable us to exchange and harness information MUCH more effectively than we currently can. In reference to your idea of how GUIDs should be assigned, you said it yourself in your previous post: "we're pretty close to this already". If building an infrastructure of GUIDs only allows us to do incrementally more than we can already now, then I wonder whether we need to bother with GUIDs at all. I would like to see the infrastructure established that allows us to do much more than we can right now -- and that largely hinges on the reusability aspect of GUIDs. > Alternatively, let users decide what mappings they want to make between > you and ITIS. Expertise is rare and widely distributed. I think you're > making things harder for yourself than the need to be. No, I'm trying to help foster a foundation for information exchange that will make things easier for future generations of biologists (and non-biologists). With a few simple standards and conventions and definitions, I think we can develop a system of GUIDs that lets us harness biological information much more effectively than is possible now. > >> If we think of the scientific literature, many paper have at least two > >> GUIDs (DOI and PubMed), both of which are useful, and which serve > >> different purposes. > > > > What is the value of expanding that to potentially hundreds, or > > thousands of > > GUIDs for each paper -- one GUID from each database that has a table of > > literature records? Wouldn't our information exchange be much more > > efficient if we all adopted (or at least mapped to) either the DOI or > > the > > PubMed GUID (or both)? If so, why doesn't this same logic apply to > > taxon > > names? > > I guess my point was that this is a case where more than one GUID > exists for the "same" thing (a publication), and we manage to cope. > Yes, "one GUID to rule them all" might be nice, but I just don't buy > that it's going to happen any time soon. Just look at the discussion > this topic has generated... Well, maybe we need two different discussion lists: 1) How to use GUIDs to make what we already do a bit easier to manage (low cost, fast implementation, incremental improvement); and 2) How to use GUIDs to dramatically change the way biological data is exchanged (higher cost, slower implementation, fundamental improvements). > Again, I think we make a mistake if we equate GUIDs with solving all > our problems. Rather, I suggest they give us an infrastructure on which > to build tools for mapping names/concepts/whatever. I think we are in full agreement on this. I don't think that GUIDs can solve all of our problems any more than you do. However, I think they offer the potential of solving a lot more problems than you seem to be reaching for. In a latr post, you wrote: > GUIDs enable you to explicitly identify objects, that's all. We agree on this point -- but if I understand your position correctly, the "objects" are the records in a database. In my view, the "objects" are definable, abstract nomenclatural objects that are shared across many, many databases. I also agree with your prior comment that converting LUIDs to GUIDs using the format "<my database server>:<my data type>:<my id>" is very easy. I just don't think it allows us to do much more than we already can do (as magnificently demonstrated by the taxonomic web portals that you and the uBio folks have developed). Aloha, Rich

1 0

Re: Topic 3: GUIDs for Taxon Names and Taxon Concepts
by Richard Pyle 03 Nov '05

03 Nov '05

There seems to be a great deal of confusion and misunderstanding in this discussion, and I apologize for whatever extent I am to blame. Several big issues are crossing paths. I don't know why the "centralized" issue cropped up, but it is, in my mind, tangential to (what should be) the main thrust of this discussion. > The idea that only the resolution system needs to be able to > distinguish between specimens, taxon names, etc., seems unfortunate. I agree. > Assigning GUIDs solely to basionyms strikes me as crazy -- I'd suggest > most taxa aren't known by their basionyms. I'd advocate GUIDs for every > name string (with the possible exception of orthographic variants, > spelling mistakes, etc.). By "Namestring", do you include author, our just taxonomic nomenclatural elements? In either case, why even bother establishing a GUID for taxonomic names at all? Why not just use the namestring itself? Moreover, I don't think anyone has suggest that GUIDs be assigned "solely" to basionyms. The point is, there shouldn't be six different "units" to which GUIDs are assigned to represent "taxon names" [basionyms, combinations, namestrings, namestrings with authors, concept definitions, name usage instances, etc.] > Lastly, "imposing standards" is the wrong way to think about this. > Standards win support if they work, and are adopted. I'd suggest this > stuff will happen if people make compelling applications that others > make use of, not because TDWG decides what should be done. O.K., my choice of the word "imposing" was bad. I should have said something like "implementing". The one lesson that the web has taught us more vividly than decentralization is the power of standards for information exchange. We could have all invented our own version of DarwinCore for exposing specimen records to the internet, and allowed natural selection to take its course such that only the most useful few versions survived -- but I don't think that would have been the most effective path to where we are now (and where we could be soon, once DarwinCore V2 is ratified and mapped against ABCD elements). > So, my final question is, what is wrong with having each taxonomic > database serve their own GUIDs for their own data (using an agreed > format, such as RDF), and where possible GUIDs from different sources > are mapped (e.g., a name string in IPNI to one in uBio). Users employ > whatever GUID they find useful -- at least we then know what digital > object they are referring to. To me, GUIDs are only valuable and serve the information exchange needs of our community if they are, to some extent at least, reusable. I do not understand the value of assigning GUIDs to the records in my taxonomic database, if I am the only one who will ever use them. I understand the practical value of establishing "local" GUIDs to my taxon name records independently from other databases, if the long-term goal is to eventually map my GUIDs to the corresponding "equivalent" GUIDs of other databases. But that brings me back to the original point I've been trying to make: that mapping can only be done effectively if we have equivalent objects to map. Right now, there are a half-dozen competing ideas about what a "name" object is (or should be). Having spent the past year beating my head against a wall trying to map my local taxonomic database records to ITIS TSN's, I can speak with first-hand experience how utterly INefficient it can be to create such cross-walks when a "Name" record in ITIS means something different from a "Name" record in my database. Donald started out this discussion by suggesting that "Taxon Name" objects might be thought of as fundamentally different from "Taxon Concept" objects (in an analagous way to how publication objects are fundamentally different from specimen objects). If you agree with this, then it would be nice if we could find a standard line to draw between these two objects, so that when we later try to cross-walk our respective datasets, we're mapping apples to apples, and oranges to oranges (rather than apples to bananas and then back to oranges -- which aptly represents what I'm having to resort to in mapping my taxonomic data records to ITIS records). > If we think of the scientific literature, many paper have at least two > GUIDs (DOI and PubMed), both of which are useful, and which serve > different purposes. What is the value of expanding that to potentially hundreds, or thousands of GUIDs for each paper -- one GUID from each database that has a table of literature records? Wouldn't our information exchange be much more efficient if we all adopted (or at least mapped to) either the DOI or the PubMed GUID (or both)? If so, why doesn't this same logic apply to taxon names? 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

1 0