- tdwg-tag - lists.tdwg.org

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

Re: Different reasons for different GUIDs
by Nozomi Ytow 13 Sep '05

13 Sep '05

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 Richard Pyle 13 Sep '05

13 Sep '05

Thanks, Donald. > There are different situations (use cases) in which we may require GUIDs. > The service characteristics of GUIDs may not always be the same. I agree, and this is true at two levels. At one level, the GUID needs may be different for different data domains (i.e., top-level object categories: Taxon Names, References, Specimens, Agents, etc.) At another level, the GUID needs for different use cases *within* a data domain may differ. > 3. Users can assume that data records relate to the same real-world object > if and only if they share the same GUID. > > I think that we have generally assumed that all our GUID uses will require > this additional function, but this is the part that will get very > expensive to implement. Why would it be so much more expensive to implement? > I believe that we should take a case-by-case decision on > whether the additional infrastructure is really required to support this > level of integration. I'm not sure I follow. Are you saying that it requires additional infrastructure to support the notion that "Users can assume that data records relate to the same real-world object if and only if they share the same GUID"? But under what circumstances could users ever assume that data records relate to the same real-world object when they do *not* share the same GUID? It would seem to me that it would require a human brain to reliably ascertain that GUID A refers to the same real-world object as GUID B. And once that determination is made, the "expensive" part is already done. At that point, the GUIDs should be (objectively) "synonymized", so that future users who reference either GUID do not have to invest the same expensive decision-making process involved with ascertaining their equivalency. Maybe I've completely misunderstood your point, but I guess what I'm struggling to understand is, when presented with two data objects with different GUIDs, under what circumstances could a user "assume" anything other than that they are not the same real-world object? > As an example, I can see excellent reasons for us at least to try for > benefit 3 for specimen records, and also probably in some way for taxon > names and publications (whatever actual form the identifiers for these may > take). However (I think, like Rod) I am not totally convinced > that we will > need to manage GUIDs offering benefit 3 for taxon concepts. O.K., now I think I understand where you are coming from (i.e., the "fuzzy" nature of taxonomic concept GUIDs, and what they really represent). As I have argued during the TCS/LC discussions, my feeling is that a Taxonomic Concept object should not receive a GUID that is disconnected from the [TaxonName]+[Publication] pair of GUIDs. In other words, I think that a Concept should be uniquely identified via a name-usage instance (specifically, the name-usage instance that defined the concept). But I may not be in the majority on this. > We should use > GUIDs (with benefits 1 and 2) for taxon concepts, and our taxon concepts > should reference names and publications which probably have the stronger > kind of GUIDs (with benefits 1-3). The coupling of a name GUID and a > publication GUID would then be a unique combination that would still allow > concepts to be compared. Exactly....so why assign a different GUID to the Concept? Or, perhaps put a different way, why assign a different GUID to the *name* (in the Taxonomer paradigm that names do not exist as stand-alone objects independent of usage instances)? > This is just an example, but indicates that we need to think hard > about the > use cases for each data object class and its associated GUIDs. Agreed! Aloha, Rich Richard L. Pyle, PhD Ichthyology, 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

Different reasons for different GUIDs (Was: GUIDs, LSIDs, and metadata)
by Donald Hobern 13 Sep '05

13 Sep '05

Richard Pyle wrote: > One paradigm might have each major database create its own LSID: > > urn:lsid:catalogoffishes.org:SPNO:123456 > urn:lsid:gbif.org:ECAT:876543 > urn:lsid:itis.gov:TSN:567890 > > But then we're burdoned with the task of cross-mapping each of these, and > also preserving the legacy IDs into perpetuity after we've eventually > converged on a single taxon name GUID system. This indicates a general issue that we need to consider and which may make the whole problem a little simpler for us in some areas. There are different situations (use cases) in which we may require GUIDs. The service characteristics of GUIDs may not always be the same. It seems reasonable for us to think of a system which associates GUIDs with every data object shared by anyone using TDWG standards. These objects will represent a wide range of different types of record (specimen, collection, taxon name, taxon concept, synonymy assertion, publication, author, user, etc.). Use of genuinely _global_ identifiers in all of these cases will have the following benefits: 1. Users can reliably request associated data items simply by knowing the GUID assigned to them by the data provider. For example, I can view a specimen record and then request an associated taxon concept record identified within the specimen record by GUID. 2. It may simplify a data provider's own task in providing cross-references between data elements which are all under their own control. This is a compelling set of reasons for using GUIDs, and for their being resolvable. Such GUIDs should be relatively simple to manage and we could put together many different solutions that would satisfy these requirements. There is however a further requirement that may only apply in certain situations and for certain classes of data: support for _different_ data providers to re-use the _same_ GUID if they are sharing data for the same real-world object (collection, specimen, etc.). For example institutionA is the first body to reference a taxon concept published under the name Aus bus in publicationC. If institutionB subsequently wishes to reference Aus bus sensu publicationC, they would need to find and reuse the same idengtifier. The benefit from this would be as follows: 3. Users can assume that data records relate to the same real-world object if and only if they share the same GUID. I think that we have generally assumed that all our GUID uses will require this additional function, but this is the part that will get very expensive to implement. I believe that we should take a case-by-case decision on whether the additional infrastructure is really required to support this level of integration. As an example, I can see excellent reasons for us at least to try for benefit 3 for specimen records, and also probably in some way for taxon names and publications (whatever actual form the identifiers for these may take). However (I think, like Rod) I am not totally convinced that we will need to manage GUIDs offering benefit 3 for taxon concepts. We should use GUIDs (with benefits 1 and 2) for taxon concepts, and our taxon concepts should reference names and publications which probably have the stronger kind of GUIDs (with benefits 1-3). The coupling of a name GUID and a publication GUID would then be a unique combination that would still allow concepts to be compared. 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. Such a system would require every data provider to check a global registry to make sure that any particular taxon concept did not already have a GUID. This is just an example, but indicates that we need to think hard about the use cases for each data object class and its associated GUIDs. 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 ---------------------------------------------------------------

1 0

Re: GUIDs, LSIDs, and metadata
by Roderic Page 12 Sep '05

12 Sep '05

On 12 Sep 2005, at 08:40, Peter Dawyndt wrote: > > It seems that the solutions worked into the StrainInfo.net portal have > many > common grounds with the problems encoutered with the integration of > taxonomic > names into a single coherent system. In this context I also recommend > the > Taxonomic Databases Working Group to take a look at the experimental > work done > by George Garrity of Bergey's Manual Trust to work bacterial taxonomic > names > into the DOI framework. After all, it seems to me that the DOI > framework > currently offers a far more extended framework of software solutions > and > organisational issues that outreach those of the LSIDs at present. An > essential > thing that is missing in the latter framework seems to be a > well-thought about > business plan to guarantee the long-term survival of the GUID system. > Also it > seems a bit like reinventing the wheel to me to overlook as system > that has > already gone through the 'proof-of-principle' stage. We already have a > morbid > growth of identifiers that are piling up our information systems, so > it would be > unwise to put our effort into the proliferation of network standards > that cover > the same domain. DOIs as presently implemented have limitations, especially the lack of any way of knowing what kind of output the DOI will yield. LSIDs specify that any LSID will resolve to RDF metadata, and also provides an explicit mechanism for downloading associated data. For example, the LSID urn:lsid:sid.zoology.gla.ac.uk:id:6 resolves to this metadata: <?xml version="1.0" encoding="utf-8"?><rdf:RDF xmlns:e="urn:lsid:sid.zoology.gla.ac.uk:predicates:" xmlns:a="http://purl.org/dc/elements/1.1/#" xmlns:d="http://www.w3.org/2000/01/rdf-schema#" xmlns:b="http://purl.org/dc/elements/1.1/" xmlns:c="urn:lsid:i3c.org:predicates:" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" > <rdf:Description rdf:about="urn:lsid:sid.zoology.gla.ac.uk:id:6"> <c:storedas rdf:resource="urn:lsid:sid.zoology.gla.ac.uk:id:6"/> <rdf:type rdf:resource="urn:lsid:i3c.org:types:content"/> <b:format>image/tiff</b:format> <d:label>6.TIF</d:label> <e:sem rdf:resource="urn:lsid:sid.zoology.gla.ac.uk:predicates:sem"/> <a:title>Image of Dennyus hirundinis</a:title> <a:date>1997-05-23</a:date> <a:creator>Vince Smith</a:creator> </rdf:Description> </rdf:RDF> The "storedas" tag tells us there is data associated with this LSID, the "format" tag tells us it is a TIFF image. If you resolve this LSID in Firefox (lsidres:urn:lsid:sid.zoology.gla.ac.uk:id:6), you'll be able to get the TIFF image (on a Mac OS X machine, or a PC with Quicktime installed, the image will load in the browser window, otherwise you will be prompted to save the image). The point of all of this is that I can write scripts or programs that can make use of LSIDs, for example, by aggregating them into a local knowledge base. To my mind, this is where the true power of LSIDs becomes apparent. I think there are at least three distinct issues to be considered: 1. Persistence, which is a social issue 2. Assigning and resolving GUIDs 3. What gets served when a GUID is resolved I think we can de-couple these, in the sense that we could use a handle system like that upon which DOIs are based, but adopt the RDF metadata approach of LSIDs. This thread has also raised the issue of mapping between multiple GUIDs. I think it is inevitable that we will have to deal with this, especially as there already exist major databases containing taxonomic information. For example, consider the task of mapping between mammalian names in DiGIR providers, and those used in GenBank (a relatively straightforward problem). In some lucky cases where we have specimen information in GenBank we can tie the two together that way, but for other names/sequences we aren't this lucky. If our databases are distributed, and run by organisations with different goals and agendas (I doubt biodiversity rates highly in NCBIs list of things to do), we will have to deal with this. > > Further reading: > > [1] P. Dawyndt, M. Vancanneyt, H. De Meyer & J. Swings (2005) Knowledge > Accumulation and Resolution of Data Inconsistencies during the > Integration of > Microbial Information Sources 17(8), 1111-1126. > http://doi.ieeecomputersociety.org/10.1109/TKDE.2005.131 > > [2] P. Dawyndt, M. Vancanneyt & J. Swings (2004). On the integration of > microbial information. WFCC Newsletter 38, 19-34. > http://wdcm.nig.ac.jp/wfcc/NEWSLETTER/newsletter38/a3.pdf > > [3] P. Dawyndt, B. De Baets, X. Zhou, J. Ma & J. Swings. > StrainInfo.net: Holding > a wealth of downstream information on microbial resources right in our > hands. > http://www.cpdr.ucl.ac.be/bioinf/papers/bioinf/bioinf_dawyndt.pdf > > Also check out the background document and discussion papers that came > out of > the specialist workshop on "Exploring and exploiting microbiological > commons: > contributions of bioinformatics and intellectual property rights in > sharing > biological information" at http://lmg.ugent.be/bioinf-ipr/ Interesting reading. 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