September 2005 - tdwg-tag - lists.tdwg.org

GUID for concepts?
by Nozomi Ytow 14 Sep '05

14 Sep '05

Donald, > I think that in practice the potential taxon sensu Berendsohn (1995) is > precisely what TDWG has primarily been addressing in recent discussion of > taxon concepts. I don't think so because AccordingTo is optional. We are in denger to have other than potential taxa. I don't see any reason that AccordingTo to be optional in TCS, because there must be a data source, i.e. the database itself, at least. Cheers, JMS

1 0

Re: Different reasons for different GUIDs
by Peter Dawyndt 14 Sep '05

14 Sep '05

Roderic wrote: "I say 'same' because, leaving taxon-concepts aside, the presence of homonyms between the codes makes mapping names as strings problematic" Richard replied: "Indeed! One of the main reasons for using GUIDs instead of text strings in the first place!!" There's two thing in getting rid of homonymy. The first is entity identification, which is indeed as Richard said what the assignment of unique identifiers is about. The second thing is name resolution, ie. the name to the correctly identified entity. And as I said the latter might either need user-intervention (question raised from the resolution system) or context-dependent resolution. Here's a simple example that has nothing to do with taxa: Suppose there are three people called "Roderic Page" on this planet, one in the UK, one in Hawaii and one in Belgium. Let's consider we can take their social security number (SSN) as a global unique identifier, so each of the three will have been assigned a different SSN. If we have their SSN, then their identity is guaranteed to be unique. If we lookup their identity by means of their name (knowing that there is homonymy) than will come up with three possible people. So we will need additional information to resolve between the options. Either we can ask about their country of origin, which would be sufficient in this case for resolution, or if the name appears in a text we could extract enough contextual information to single out original name to one of the possible entities. This is what the human brain would do to resolve names to concepts they know, and this is exactly what computers do when performing context-sensitive information. In the case of taxonomic names, apart from the name itself, the original publication, authors of the publication, or whatever other information could be considered as contextual information that helps resolving the name. What would be sufficient (at the end there should be one entity left after resolution) and necessary (we do not want to require too much context information, otherwise the resolution might become unpractical) context information for resolving taxonomic names, I leave to the experts in the field. As was pointed out before by someone: the GUIDs help to 'remember' the outcome of the resolution, so that each instance of the name needs to be resolved only once and is replaced (at least through the eyes of the information system) by the corresponding GUID. One also has to take into account that once there is a clearly established system of globally unique identifiers that is accepted by a community, than all of the problems are resolved if the assignment of identifiers for new entities is carefully organized. All we are stuck with is the legacy of the past, as to assign the identifiers to the occurrences of the names that carried no identifiers with them. Peter Dawyndt

1 0

Re: Different reasons for different GUIDs
by Peter Dawyndt 14 Sep '05

14 Sep '05

Rod, > Of course, an electronic version of a paper, and its abstract stored in > another database are not the same thing (at least, not electronically). > This is an example were a simple cross reference can link the two GUIDs > (in many cases, the PubMed record provides this cross reference). there's a thin line between entities and instances, and dependent on the application some 'things' that were previously regarded as instances might be raised to the entity level. The Object Management Group (OMG) has created a nice standard for that [Cattell R & Barry D (1997). The Object Database Standard: ODMG 2.0. Morgan Kaufmann Publishers] which is regarded as the 'standard model' for object oriented design. They use a slightly different terminology where-in they use the term 'first class object' for 'entity' (an object carrying identity; in other words has a unique identifier assigned to it) and a 'literal' (an object without identity as an instance that does not need identity, because no tracking and tracing on occurrences of the object are regarded necessary). However, at some point in time some applications might need tracking and tracing of literals, so that they are turned into first-class object by assigning identity to them, and finding instances of their occurrence (this is exactly the task that is ahead of us to turn life science literals (eg. pure names that had no previous tracking capabilities) into first-class objects (with a GUID assigned to them). In the example you mention, my intuition would say that in this particular case their is no need to assign two different GUIDs to both the full text version and the abstract version of the paper. What we need here I think is the application of what is now commonly seen as a need for multiple resolution, where a single identifier (in this case a GUID referencing a 'publication' object) is made actionable, in such a way that several services can be attached to the single identifier. In the case you mentioned, this would be one service that directs the user to the full paper version of the article (if he has authorization to do so) and a second service that directs the user to the abstract version of the paper. Only at the application level should then be decided how these services are used. One possibility would be give the user a list of all possible services (eg. do you want full version or abstract only). Another could be to check wether the user has authorization to see the full paper version of the paper. If so, then make use of the full paper version service, otherwise use the abstract only service. This issue is termed 'making an identifier actionable' in the DOI handbook, which I recommend as mandatory reading for all the people in this discussion group. In not only deals with technical issues on the introduction of GUIDs, but also tackles social and legal (IPR) implications. Also the business plan of DOI is well documented. > Regarding mapping between GUIDs, I suspect the mapping may get very > complicated, and a simple tree might not be appropriate. Attached is an > example of relationships between names in MOBOT, based on RDF I > generate for LSIDs for MOBOT names. This is a nice example of an entity-relationship diagram, where indeed the relationships between entities can be much more complicated than only a tree-like structure. What I was trying to explain in a previous mailed was merely a system to manage identity (uniqueness) of entities alone. The example you have shown, reminds me of the work done by George Garrity on the taxonomy of bacteria, for which he has made a nicely animated presentation that can be downloaded from http://www.cpdr.ucl.ac.be/bioinf/papers/bioinf/BrusselsGarrity0710052b.ppt this also shows the complex interrelationsships that have been created during the establishment of new taxon concepts and names. Peter Dawyndt

1 0

Re: Different reasons for different GUIDs
by Roderic Page 14 Sep '05

14 Sep '05

Hmmm, I'm struggling to see how adding name-usage instances (of which there will be an awful lot more than just names) will make this diagram any less complex. In fact, the names in the diagram could be regarded as name-usages (if I just tack on the literature source), omitting subsequent usages of a name. I take it you are limiting the mapping of Taxon Name GUIDs to be between GUIDs for the "same" name in different databases? I say "same" because, leaving taxon-concepts aside, the presence of homonyms between the codes makes mapping names as strings problematic (indeed, GenBank uses names to map between its databases an external sources, and there are quite a few cases where this mapping is erroneous). I should point out that the picture I attached is a particularly messy example where the plant species Oxylobium lineare has been moved to a new genus (Gastrolobium), but the resulting binomial (G. lineare) already exists (although it is treated as a synonym of G. callistachys). Consequently, a new species epithet was created, resulting in G. ebrachteolatum. I found this out the hard way when looking at TreeBASE names, trying to figure out how come a sequence for Gastrolobium ebrachteolatum was listed in GenBank as being from Oxylobium lineare. Furthermore, these are just the links represented in MOBOT. There should be additional links (for example, Oxylobium linearis and Callistachys linearis must be synonyms). Rod On 14 Sep 2005, at 07:05, Richard Pyle wrote: > Hi Rod, > >> Regarding mapping between GUIDs, I suspect the mapping may get very >> complicated, and a simple tree might not be appropriate. Attached is >> an >> example of relationships between names in MOBOT, based on RDF I >> generate for LSIDs for MOBOT names. > > I think the diagram you sent seems complex only because it endeavors to > create direct linkages between name objects. As far as I'm concerned, > the > only linkages shown on your diagram that should be treated as a direct > NameObject-NameObject links are the "basionym" links (actually, in my > view, > this kind of relationship does not even need to exist at all). All of > the > other links should be routed between and among Name Objects > indirectly, via > name-usage instances. The complexity is then passed to the network of > name > usages, and would not affect the mapping of Taxon Name GUIDs that Peter > described. > > Aloha, > Rich > > 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/ ___________________________________________________________ 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: Different reasons for different GUIDs
by Roderic Page 13 Sep '05

13 Sep '05

This is probably slightly off the topic, but in the case of literature there are two GUIDs already available for many recent papers: DOIs assigned by publishers, and PubMed ids assigned by NCBI (I think we can treat the later as GUIDs, especially if we wrap them in LSIDs as done by the Biopathways Consortium). Of course, an electronic version of a paper, and its abstract stored in another database are not the same thing (at least, not electronically). This is an example were a simple cross reference can link the two GUIDs (in many cases, the PubMed record provides this cross reference). Regarding mapping between GUIDs, I suspect the mapping may get very complicated, and a simple tree might not be appropriate. Attached is an example of relationships between names in MOBOT, based on RDF I generate for LSIDs for MOBOT names. 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/

1 0

Re: Different reasons for different GUIDs
by Donald Hobern 13 Sep '05

13 Sep '05

I think that in practice the potential taxon sensu Berendsohn (1995) is precisely what TDWG has primarily been addressing in recent discussion of taxon concepts. TCS can accommodate expression of other mechanisms for defining taxon concepts but does not (at least yet) do much to allow us to reason about them. I agree that we should be aiming to create tools that wherever possible can give us an assessment of which taxon potential taxa cluster closely enough that we can treat them as a 'granule'. That is a further challenge and one that will probably largely depend on what sort of information taxonomists and others are really prepared to put into a standard like TCS. I also note that the subject I raised in my previous e-mail was well addressed (with support on both sides) by earlier posts from Rich and Peter. My fault for responding to something while still reading. 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 Nozomi Ytow Sent: 13 September 2005 13:58 To: TDWG-GUID(a)LISTSERV.NHM.KU.EDU Subject: Re: Different reasons for different GUIDs Donald and all, > However there is probably insufficient benefit for > us to gain from having a system where strong GUIDs are assigned to every > taxon concept that any provider wishes to reference. Exrepssion "every taxon concept" implies that we can establish identity of taxon concept. I don't think it is possible execpt potential taxon sensu Brendsohn (1995), i.e. combination of name string and publication. What we need for the benefit 3 is not GUID of 'each' taxcon cocnept but a mechanism to give an approxiamtion of a taxon concept/taxon concepts (I'm not convince how can I count taxon concepts) can be used as a granule. JMS -- Dr. Nozomi "James" Ytow Institute of Biological Sciences / Gene research center University of Tsukuba Tsukuba, Ibaraki 305-8572 Japan

1 0

Re: Different reasons for different GUIDs (Was: GUIDs, LSIDs, and metadata)
by Peter Dawyndt 13 Sep '05

13 Sep '05

Donald Hobern wrote: > 3. Users can assume that data records relate to the same real-world object > if and only if they share the same GUID. Here's some technology that has worked for us to assign unique identifiers to objects for which there is no prior universally adopted system for assigning and recognizing persistent and unique identifiers (it uses the terminology of object, entities and instances orginating from the object-oriented community and is commonly adopted by people working in the text mining field). In this context, the task is to map each instance of a given object to it's corresponding entity (by using a unique identifier). During this process, instances of entities that have no unique identifier assigned to them, are assigned a new unique identifier (accumulative learning). How this mapping from the instance of an entity (usually a textual description such as the reference to a publication, the label of a specimen or the name of a taxon) to the unique identifier of the entity is object-dependent and may require the input of expert knowledge. Once a unique identifier is assigned to an entity, the entity can be made more "intelligent" by incorporating it in solid cross-reference schemes with other entities (using their unique identifiers). However, there's two problems that occur during the mapping of instances (textual descriptions) and the unique identifiers: 1. the same unique identifier is assigned to instances of different real-world entities (eg. because they use the same textual description). These are called false-positive assignments. Some ambiguities during the assignment process can be resolved by making the mapping algorithm context-dependent, taking more information into account than only the textual description of the instance itself, and in some cases it the mapping algorithm could even decide that is impossible to automatically assign unique identifiers and ask for some form of user intervention. Apart from that, it is also possible after the assignment of unique identifiers to do intrusion detection by finding inconsistencies in the assignment of identifiers that come out of the cross-referencing of the entity with other entities (eg. some taxon name is assigned to both specimen of mammals and fungi, which could be the case if the assignment of names to taxa has not been unique over all kingdoms; or two sequences of the same gene from the same specimen are too dissimilar). If such cases are detected, it would mean that the instances need to be split and at least one new identifier would need to be created to discriminate the two entities (Even better would be in such cases to create two new identifiers, and linking them to the original identifier which would become obsolete for future reference, but could serve to resolve existing references that make use of the identifier). 2. different unique identifiers are assigned to instances of the same entity. These are called false-negative assignments. Although this particular case is generally less harmful than the previous case, it could mean that queries based on cross-referencing schemes that make use of the unique identifiers could come up with less-than-complete information (while in the previous case they would come up with incorrect information). When false-negative assignments are detected (and again many domain-dependent solutions have been suggested, in which an investigation of the cross-referencing schemes usually play an important role) they can simply be resolved by merging the identifiers so that they represent the same entity. Splitting and merging identifiers that were assigned and represent different or identical entities respectively can be easily done by representing them in a tree-like structure (tree are either splitted completely, or the splitted subtrees are still connected by the same root which carries and obsoleted identifier) and cross-referencing schemes can take into account the relationships represented by these tree-like structures. Diversity of unique identifiers for the same entity can be avoided to recommend the root of the tree (or subtrees in case of splitted trees) as the identifier to use for future cross-references. This technology has a number of practical advantages, most and forall that the assignment of unique identifiers is completely decoupled from the process of error detection and correction. Fact is that unique identifiers need to be assigned to implement solid cross-referencing schemes and that solid cross-referencing schemes are valuable tools for the detection of erroneouos assignments of unique identifiers (which came first, the chicken or the egg?). In this phylosophy, the assignment of unique identifiers is thus no longer seen as a one-step process, but as a perpetuous process of identifiers assignments and quality control. And of course it should be a major concern to make the mapping between unique identifiers assigned to entities a 1:1 relationship as much as possible, by making the mapping algorithms as intelligent as possible. But again maintaining a 1:1 relationship only exists in the perfect world (even if there is only one authority that can assign new identifiers) and we should thus come up with schemes that work in practice, as the one descibed above. > 2. It may simplify a data provider's own task in providing cross-references > between data elements which are all under their own control. Most of the cross-references I see will between entities that are not under the control of a single data provider. At least most data providers will want to hook up their own data within a broader network of information source of the life sciences. That is where actionable, persistent and globally unique identifiers really come into play I think, just to keep autonomous and heterogeneous data sources as independent as possible while enabling to make an extensible network of cross-references feasible. A lot of the cross-references already are out there somewhere. Having them nicely stored in public databases would be ideal, and therefore a lot of work is done to extract cross-reference relationships from public literature databases such as PubMed. It is worthwhile to take a look at what is moving in the community of people that try to extract functional pathways from the free text in the scientific literature. All of them are making use of one or another system to assign unique identifiers (not with the purpose of making them globally unique, but merely only unique in the context of their application). The intelligence they can currently reach with natural language processing to avoid false-positive and false-negative cross-references (good old Chomsky's theory is finally finding it's way into practice) is quite amazing. Cheers, Peter Dawyndt

1 0

Re: Different reasons for different GUIDs
by Richard Pyle 13 Sep '05

13 Sep '05

> Hmmm, I'm struggling to see how adding name-usage instances (of which > there will be an awful lot more than just names) Absolutlely! Sometimes hundreds or thousands of usages per name. But if computers are good for anything, they're good for managing large volumes of information. > will make this diagram > any less complex. In fact, the names in the diagram could be regarded > as name-usages (if I just tack on the literature source), omitting > subsequent usages of a name. It's not less complex in a visual representation sense, just in a GUID-management sense. > I take it you are limiting the mapping of Taxon Name GUIDs to be > between GUIDs for the "same" name in different databases? I believe that was the point that Peter was on about, yes. True "duplicate" GUIDs. > I say "same" > because, leaving taxon-concepts aside, the presence of homonyms between > the codes makes mapping names as strings problematic Indeed! One of the main reasons for using GUIDs instead of text strings in the first place!! > I should point out that the picture I attached is a particularly messy > example where the plant species Oxylobium lineare has been moved to a > new genus (Gastrolobium), but the resulting binomial (G. lineare) > already exists (although it is treated as a synonym of G. > callistachys). Consequently, a new species epithet was created, > resulting in G. ebrachteolatum. I found this out the hard way when > looking at TreeBASE names, trying to figure out how come a sequence for > Gastrolobium ebrachteolatum was listed in GenBank as being from > Oxylobium lineare. Furthermore, these are just the links represented in > MOBOT. There should be additional links (for example, Oxylobium > linearis and Callistachys linearis must be synonyms). I'd imagine hundreds, or thousands of cross links via usage instances. But the point is, the currency by which taxon names are dynamic at all, is the Name-usage instance. Some people get fidgety when they try to contemplate all the name-usages of all the name objects (sort of like contemplating the billions and billions of stars within each of the billions and billions of galaxies). But the system doesn't need to be complete to be useful. It would grow gradually over time as people needed to reference Name-usage instances. In the simplest form, people might start by plugging in only those name-usage instances that constitute Code-compliant original descriptions for the taxa in their own area of interest. The botanists might further plug in those name usage instances that constitute new combinations. When someone revises a whole group and works out a complete revision of a group with robust synonymies, they might go ahead and plug in the Name-usage instances covered by his/her work. The point is (getting back to my original post to this list), it would be designed in an open-ended way, such that it can be scaled up over the years, decades, (centuries?) to come, as all of this information is, evenutally, captured in a structured digital form. If done well, allowing for such long-term scalability should impact today's needs only trivially. If today's needs are simply to get all the original descriptions, then fine -- but structure them as name-usage instances that can be expanded as research effort allows/provides. Also, don't think of it as one person or group of database nerds doing all the work. Rather, an open-access system would encourage the taxonomic world to participate. If done *really* well, the tools associated with plugging the data in could be wrapped up into desktop software tools that actually make a taxonomists job a LOT easier and more efficient -- thereby providing a strong incentive to participate. Aloha, Rich

1 0

Re: Different reasons for different GUIDs
by Richard Pyle 13 Sep '05

13 Sep '05

Hi Rod, > Regarding mapping between GUIDs, I suspect the mapping may get very > complicated, and a simple tree might not be appropriate. Attached is an > example of relationships between names in MOBOT, based on RDF I > generate for LSIDs for MOBOT names. I think the diagram you sent seems complex only because it endeavors to create direct linkages between name objects. As far as I'm concerned, the only linkages shown on your diagram that should be treated as a direct NameObject-NameObject links are the "basionym" links (actually, in my view, this kind of relationship does not even need to exist at all). All of the other links should be routed between and among Name Objects indirectly, via name-usage instances. The complexity is then passed to the network of name usages, and would not affect the mapping of Taxon Name GUIDs that Peter described. Aloha, Rich

1 0

Re: Different reasons for different GUIDs
by Richard Pyle 13 Sep '05

13 Sep '05

Hi Peter and Donald, Peter: Thank you for that excellent and cogent description. I found myself nodding my head in agreement at essentially every point you made. In particular, this passage captured exactly what I hoped to express (but perhaps failed) in earlier posts: > And of course it should be a major concern to make the > mapping between unique identifiers assigned to entities a 1:1 relationship as > much as possible, by making the mapping algorithms as intelligent as possible. > But again maintaining a 1:1 relationship only exists in the perfect world (even > if there is only one authority that can assign new identifiers) and we should > thus come up with schemes that work in practice, as the one descibed above. Donald: > I think that in practice the potential taxon sensu Berendsohn (1995) is > precisely what TDWG has primarily been addressing in recent discussion of > taxon concepts. TCS can accommodate expression of other mechanisms for > defining taxon concepts but does not (at least yet) do much to allow us to > reason about them. > > I agree that we should be aiming to create tools that wherever possible can > give us an assessment of which taxon potential taxa cluster closely enough > that we can treat them as a 'granule'. That is a further challenge and one > that will probably largely depend on what sort of information taxonomists > and others are really prepared to put into a standard like TCS. I agree completely. If we can agree that taxon name units can be objectively (for the most part) defined(*), and that "documentation" units (publications, references, whatever) can be objectively (for the most part) defined(*), then I think we automatically have a mechanism to uniquely identify name-usage instances that can be objectively (for the most part) defined. Rather than get bogged down in trying to come up with a satisfactory "semi-objective" definition of which name-usage instances rise to the level of potential taxa, or full-blown "taxon concepts", I think we're better-off hard-indexing the raw name-usage instances and secondarily applying algorithms that allow "clusters" of these name-usages to emerge as potential or likely concept "granules". The relevant question in this context is whether "Taxon Concepts" represent their own distinct data domain worthy of a dedicated GUID system, or not. My hope is that someone on this list who believes that concepts can (and should) be defined separately from clusters of name-usage instances, and receive their own GUID as such (separate from names), will outline that perspective. (*)=Exactly how each of these two things is defined remains an open question, but the point is that whatever definition we end up with, it will likely be one incorporating very minimal subjectivity. Aloha, Rich

1 0