<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Thanks to all of you for taking the time to explain your perspective on
the issues relating to taxon names and their identifiers. I suspect
that some of this was probably explained last
year in earlier threads that I zoned out on, so thanks for your
patience in "re-explaining" - I'm understanding this better now. For
example, I think I "get" the reason for the use of UUIDs that Pete and
Dima explained - thanks for explaining that again. I see the problem
with character encodings in URIs, etc. <br>
<br>
I think that part of the difficulty that we are having in nailing down
this issue is that different people have different things that they
want their identifiers to "do". In a sense this is a good thing
because "clever" GUIDs actually CAN do multiple things at once. Some
of these things are:<br>
1. uniquely identifying a resource globally<br>
2. use http as a resolution mechanism<br>
3. providing a means for tracking provenance<br>
4. providing a single, stable point of reference to which multiple
people/institutions can anchor the properties of their own resources<br>
5. providing a way to unambiguously refer to the resource in a
publication (i.e. type-able)<br>
6. providing a means for a human to find information about the thing
via a webpage<br>
7. providing a means for a computer to find information about the thing
via RDF/XML<br>
8. not change<br>
Some people are primarily interested in a few of these things. Some
people are interested in others. If the identifier is for internal or
temporary use, then it doesn't really matter what the form of the
identifier is, or whether it only meets a few of these functions. For
example a URI that is used to identify your shopping cart when you make
a purchase on amazon.com is going to be globally unique, but not stable
or type-able. A private URI that you are using to call up information
within your organization (maybe with a query string on the end) may
meet some of these functions and might actually be globally unique.
However, I would not count either of these things as a "GUID" in the
sense of an identifier for permanent, public exposure and consumption,
and intended as an object for a property in somebody else's RDF. I
would assert that a "good" GUID in that sense ought to meet all of the
8 criteria that I listed above. We know how to do those things. There
are plenty of resources online about how to achieve content
negotiation, "cool" URIs (<a class="moz-txt-link-freetext"
href="http://www.w3.org/TR/cooluris/">http://www.w3.org/TR/cooluris/</a>),
GUID
standards (<a class="moz-txt-link-freetext"
href="http://www.tdwg.org/standards/150/">http://www.tdwg.org/standards/150/</a>)
and best practices
(<a class="moz-txt-link-freetext"
href="http://www2.gbif.org/Persistent-Identifiers.pdf">http://www2.gbif.org/Persistent-Identifiers.pdf</a>
<a class="moz-txt-link-freetext"
href="http://links.gbif.org/persistent_identifiers_guide_en_v1.pdf">http://links.gbif.org/persistent_identifiers_guide_en_v1.pdf</a>),
etc.
that tell us how to do this. We have examples in our community that
show us how to do these things and people who know how to do them.
There is, therefore, no excuse for us to be creating public GUIDs that
only do part of these things. <br>
<br>
Rich provides these examples of identifiers:<br>
A. A9F435E0-8ED7-46DD-BAB4-EA8E5BF41523<br>
B. urn:lsid:zoobank.org:act:A9F435E0-8ED7-46DD-BAB4-EA8E5BF41523<br>
C.
<a class="moz-txt-link-freetext"
href="http://zoobank.org/urn:lsid:zoobank.org:act:A9F435E0-8ED7-46DD-BAB4-EA8E5BF41523">http://zoobank.org/urn:lsid:zoobank.org:act:A9F435E0-8ED7-46DD-BAB4-EA8E5BF41523</a><br>
D. <a class="moz-txt-link-freetext"
href="http://zoobank.org/A9F435E0-8ED7-46DD-BAB4-EA8E5BF41523">http://zoobank.org/A9F435E0-8ED7-46DD-BAB4-EA8E5BF41523</a><br>
E.
<a class="moz-txt-link-freetext"
href="http://lsid.tdwg.org/urn:lsid:zoobank.org:act:A9F435E0-8ED7-46DD-BAB4-EA8E5BF41523">http://lsid.tdwg.org/urn:lsid:zoobank.org:act:A9F435E0-8ED7-46DD-BAB4-EA8E5BF41523</a><br>
F. <a class="moz-txt-link-freetext"
href="http://www.google.com/search?q=Danaus+plexippus+%28Linnaeus+1758%29">http://www.google.com/search?q=Danaus+plexippus+(Linnaeus+1758)</a><br>
G.
<a class="moz-txt-link-freetext"
href="http://lsid.tdwg.org/summary/urn:lsid:zoobank.org:act:A9F435E0-8ED7-46DD-BAB4-EA8E5BF41523">http://lsid.tdwg.org/summary/urn:lsid:zoobank.org:act:A9F435E0-8ED7-46DD-BAB4-EA8E5BF41523</a><br>
H.
<a class="moz-txt-link-freetext"
href="http://darwin.zoology.gla.ac.uk/%7Erpage/lsid/tester/?q=urn:lsid:zoobank.org:act:A9F435E0-8ED7-46DD-BAB4-EA8E5BF41523&submit=Go">http://darwin.zoology.gla.ac.uk/~rpage/lsid/tester/?q=urn:lsid:zoobank.org:act:A9F435E0-8ED7-46DD-BAB4-EA8E5BF41523&submit=Go</a><br>
and then says:<br>
"But really, from the perspective of the end-user, does it matter if
it's an identifier or a service? Ultimately, they ask the questions,
and the answers appear on their computer screens."<br>
I would answer this question by saying "yes, it does matter!" - it is
important that a well-designed GUID do more than just throw something
up onto a human user's web browser. All of 8 these examples are
globally
unique (test 1). However, many of them flunk one or more of the seven
other "tests" that I've laid out above. A and B flunk test 2. I
applied test 6 all 8 of them by pasting them into Firefox to see if
they
would produce a human-friendly webpage and this test was flunked by A,
B, and E. I applied test 7 to all of them by checking them with the
OpenLink RDF browser (<a class="moz-txt-link-freetext"
href="http://demo.openlinksw.com/rdfbrowser2/">http://demo.openlinksw.com/rdfbrowser2/</a>).
Only E
passed that test. All of them are pretty rotten on test 5, although D
isn't too bad. The fact that there are at least five identifiers
suggested which might be appropriate for use in metadata (A through E)
makes the set as a whole flunk test 4. The bottom line is that not
one of the 8 suggested identifiers pass all 8 of the tests. To me that
is unacceptable. We simply should not be satisfied with that when it
is clear that we can create identifiers that will meet all 8 tests.
Lest anyone doubt me, here are three examples of "good" GUIDs created
by members of our community which pass all 8 tests; there are
undoubtedly more.<br>
<a class="moz-txt-link-freetext"
href="http://biodiversity.org.au/apni.taxon/118883">http://biodiversity.org.au/apni.taxon/118883</a><br>
<a class="moz-txt-link-freetext"
href="http://lod.taxonconcept.org/ses/v6n7p">http://lod.taxonconcept.org/ses/v6n7p</a><br>
<a class="moz-txt-link-freetext"
href="http://biocol.org/urn:lsid:biocol.org:col:35259">http://biocol.org/urn:lsid:biocol.org:col:35259</a><br>
All three pass the "cool URI" test and clearly resolve to metadata for
both humans and computers. What I am wanting for taxon names is
identifiers that pass the 8 tests I listed. <br>
<br>
An important question that I think has been underlying much of this
discussion is whether GUIDs are actually needed for names. If one
takes the position that a "name" can never be more than a string
without crossing the line into being something more complicated like a
TNU or TaxonConcept, then I think one could make the case that the
answer to this is "no". There isn't a whole lot that one would want to
know about the string that couldn't just be imparted by letting it be a
string literal. If one takes this position, then "Quercus alba L." is
a
different "thing" (i.e. resource) from "Quercus alba" or "Quercus alba
Linnaeus". It
seems that something like this is the position that Rich and the GNI
are taking.
Under this scenario, there is little point in creating URI GUIDs for
the name strings. <br>
<br>
On the other hand, if one takes the position that a name can be a
conceptual entity that has properties which include its name string(s)
and parts thereof, then it does make sense to apply GUIDs to that kind
of entity. I am thinking about a tn:TaxonName as defined in the TDWG
ontology (see
<a class="moz-txt-link-freetext"
href="http://code.google.com/p/tdwg-ontology/source/browse/trunk/ontology/voc/TaxonName.rdf">http://code.google.com/p/tdwg-ontology/source/browse/trunk/ontology/voc/TaxonName.rdf</a>),
which comes out of the TCS schema (see
<a class="moz-txt-link-freetext"
href="http://code.google.com/p/darwin-sw/wiki/ClassTaxon">http://code.google.com/p/darwin-sw/wiki/ClassTaxon</a>
for info and links
regarding TCS). A tn:TaxonName is "An object that represents a single
scientific biological name..." i.e. an "object" NOT defined as a
string. Under the TCS, it is not kosher for a tn:TaxonName to have
properties
that tell how it is related to higher taxa - this is reserved for
TaxonConcept instances. However, it is perfectly fine for an instance
of tn:TaxonName to have properties that define the parts of its name
(genus, species, and infraspecificEpithet if any) and other metadata
directly associated with the name. Assigning a "good" GUID to a
tn:TaxonName
would be a desirable thing from the standpoint of test #4 because it
would allow multiple people to assert that they were talking about the
same name without having to worry about whether they did or did not
include the author in the string and whether "Quercus lobata Née" is
the same thing as "Quercus lobata Nee". The "atomized" parts of the
name could be provided in a single unit of metadata rather than having
to repeat them for every concept like "Quercus alba L. sensu Weakley
2010", "Quercus alba L. sensu Gleason and Cronquist 1991", "Quercus
alba L. sensu Radford et al. 1968", "Quercus alba L. sensu Wofford and
Chester 2002", etc.<br>
<br>
Currently I'm following the approach for marking
up Taxon metadata that was outlined by Cam and me at
<a class="moz-txt-link-freetext"
href="http://code.google.com/p/darwin-sw/wiki/ClassTaxon">http://code.google.com/p/darwin-sw/wiki/ClassTaxon</a>
- it's based
primarily on ideas from TCS and influenced by RDF examples posted by
several people on this list (specifically it uses the Taxon Concept
parts of the unfinished TDWG ontology with is NOT a standard, but is
based on the TCS standard). We considered it to be relatively "safe"
because it was based primarily on TCS which is a ratified TDWG standard
and seems to mesh well with what most people seem to intend when they
are talking about Taxon/TaxonConcept instances. We hope that this
would avoid descending into "taxon concept hell" as would happen if we
defined our own personal idea of what we think a taxon concept is. (In
the interest of moving forward constructively in a relatively short
period of time we hope that others will follow the same practice.)
What I'm doing is
creating temporary
tc:TaxonConcept (a.k.a. tc:Taxon) resources to which I'm linking the
dwc:Identification instances. I call them temporary because I don't
really intend for others to use them and I'm hoping eventually to
replace them with links to GNUB URIs when such things exist. In a
nutshell, the RDF looks like this:<br>
<br>
<tt><tc:TaxonConcept
rdf:about=<a class="moz-txt-link-rfc2396E"
href="http://bioimages.vanderbilt.edu/taxon/19408-weakley2010">"http://bioimages.vanderbilt.edu/taxon/19290-weakley2010"</a>><br>
<tc:nameString>Quercus alba L.</tc:nameString><br>
<tc:hasName rdf:resource
=<a class="moz-txt-link-rfc2396E"
href="http://www.ubio.org/authority/metadata.php?lsid=urn:lsid:ubio.org:namebank:448439">"http://www.ubio.org/authority/metadata.php?lsid=urn:lsid:ubio.org:namebank:448328"</a>/><br>
<tc:accordingToString>Weakley, A.S., 2010. Flora of the
southern and mid-Atlantic states, working draft of 8 March 2010.
University of North Carolina Herbarium, North Carolina Botanical
Garden, Chapel Hill, NC, US.
<a class="moz-txt-link-freetext"
href="http://www.herbarium.unc.edu/flora.htm">http://www.herbarium.unc.edu/flora.htm</a></tc:accordingToString><br>
<tc:accordingTo
rdf:resource=<a class="moz-txt-link-rfc2396E"
href="http://www.herbarium.unc.edu/flora.htm">"http://www.herbarium.unc.edu/flora.htm"</a>/><br>
</tc:TaxonConcept></tt><br>
<br>
In reality the RDF is more complicated than that but for the purposes
of
discussion, these are the important features. [For now you can ignore
the "accordingTo parts because it's not really right according to TCS
and the URI is for a web page, not the actual reference.] For the
purposes of
"stupid" clients (e.g. a Linked Data browser), the tc:nameString and
tc:accordingToString literals would give them something to throw on a
screen for humans to look at. A smarter client might be able to parse
out the name string and do something clever with it. However, as
someone who has listened to Pete's preaching and is trying hard to be a
Linked Data/Semantic Web Believer, I want to put
a functioning URI as the object of the tc:hasName property so that a
real smarty-pants client could do exceptionally clever things like
decide that maybe my <i>"Quercus alba</i> L." pictures should go be
put on the same webpage as somebody else's <i>"Quercus alba"</i>
pictures and with a third person's <i>"Quercus alba</i> Linnaeus"
pictures. I don't know how to do that, but I have faith that there are
people on the list who know how, and so I want to give them the Linked
Data resources to make that possible. This is similar to the rationale
for using the URI <a class="moz-txt-link-freetext"
href="http://bioimages.vanderbilt.edu/contact/baskauf">http://bioimages.vanderbilt.edu/contact/baskauf</a>
to
refer to me rather than the strings "Steve Baskauf", "Steven J.
Baskauf", "S. Baskauf", etc. etc.<br>
<br>
As I think about it, a primary purpose of providing a URI for a taxon
name is to allow a machine to know that names which are referred to in
two different taxon concepts are the same. This can be accomplished in
one of two ways. One is simply make sure that users who are trying to
look
up two variant name strings for the same taxon name are directed to the
same
identifier. This is essentially what happens when one looks up a TSN
on the ITIS website. If I
search the ITIS website for either "Quercus alba L." or "Quercus alba",
I'm sent to the record for TSN 19290. In this scenario, there is a
single identifier for all of the lexical variants of Quercus alba L.
When comparing two taxon instances to see if they have the same taxon
name part, a
machine has virtually no work to do in order to know that two name
strings represent the same tn:TaxonName because even if the
tc:nameString literal for the taxon has a different string literal
value, as long as
the URI object of tc:hasName is the same, then the names are the same.
<br>
<br>
The situation at uBio is different. uBio assigns a different
identifier for each string and if one searches for different lexical
variants, one gets different identifiers (although as one types a name
on their website, the name version with the preferred author
abbreviation shows up at the top of the "suggestions" list). However,
although uBio provides separate identifiers for separate name
strings, the RDF metadata that is returned when the
"urn:lsid:ubio.org:namebank:448328" URI for "Quercus alba L." is
resolved includes statements like <br>
<ubio:lexicalVariant
rdf:resource="urn:lsid:ubio.org:namebank:2645936"/><br>
whose object is the URI for "Quercus alba". So although two users who
are creating tc:Taxon records for taxa with the same tn:TaxonName may
get two different uBio ID numbers for two lexical variants, the
properties of a
uBio name string includes metadata property connections which could
allow a client to figure out whether two name strings are really the
same tn:TaxonName. <br>
<br>
Now what about the GNI? At the moment, if I search for either "Quercus
alba L." or "Quercus alba", I get a web page showing "Lexical Groups"
which I guess may or may not actually be the same conceptual name. I'm
not directed to any preferred version nor am I told which ones are
considered variants of others. I don't know the algorithm for
generating the UUIDs for these strings so I can't actually look up what
RDF is returned for those Quercus alba strings, but based on the
examples of other names that Pete gave,
the RDF just seems to say "this string is the scientific name Quercus
alba" and has no information telling me what other strings are
variants. So what I'm struggling to figure out is what purpose there
actually would be for me to use any kind of GNI URI as the object of my
tc:hasName property. A URI based either on the name string or a URI
containing a UUID generated from the name string would simply tell me
that the thing that I'm talking about is that name string. That is
exactly the same information that I already provide in the literal
value of the tc:nameString property. Maybe there is a plan at some
time in the future to add RDF metadata of the kind that uBio provides
about variants and then I guess there would be a point in using a URI
with tc:hasName that resolves to that RDF. But if the GNI is only a
"dirty bucket" that accumulates every name string that anybody has ever
used in history but with little or no metadata, then I can't see that I
have any use for a URI point to it, at least as something to which I
would refer in
RDF. I'm not saying that there isn't a use for the GNI. I think what
I'm saying is that there doesn't seem to be any point in worrying about
how to create URIs for the GNI when those URIs don't "do" anything
different from what a string literal does. I think this is essentially
what Rich was saying: "that text string represents a perfectly suitable
unique identifier. There is no
need to generate a surrogate identifier like an integer number or UUID
or LSID or whatever".<br>
<br>
>From the standpoint of what I think of as the "general Bob Morris
naughty test" (am I being naughty to assert that some resource has an
rdf:type that doesn't make sense?), I believe that one could
technically use either a uBio http proxied LSID or a resolvable
identifier created from an ITIS TSN (which unfortunately does not exist
to my knowledge) to represent a tn:TaxonName. Although Rich has been
very cautionary about maintaining the distinction between ITIS TSNs,
which he believes to represent some kind of minimal TNU and uBio IDs
which he believes to represent a name string, I haven't been able to
find any evidence that it would be "naughty" to assert that either one
is a tn:TaxonName. The RDF returned when a uBio LSID is resolved does
not give any rdf:type. It simply says that the resource has a dc:type
of "scientific name". This could really mean anything we want since
scientific name is not a part of the DC type vocabulary. There is also
nothing in the RDF that defines the resource as being of the string
data type (although one of its properties, ubio:canonicalName, does).
So I can't see that I would be creating any "collision" of rdf:types by
asserting the resource to be of type tn:TaxonName. The ITIS website
does return tc:Taxon (a.k.a. tc:TaxonConcept) type information when one
looks up a TSN, but since as far as I know ITIS doesn't provide any RDF
describing the resources identified by their TSNs, there isn't any
collision if I assert that such a resource is a tn:TaxonName. Also, if
one reads the information that was referenced earlier in the thread at
<a class="moz-txt-link-freetext" href="http://www.itis.gov/pdf/faq_itis_tsn.pdf">http://www.itis.gov/pdf/faq_itis_tsn.pdf</a> , it seems pretty clear that
ITIS intends for the subject of their TSNs to be names, not taxon
concepts even if the metadata they send to humans on their website
seems to say otherwise. <br>
<br>
As far as what URI I stick in my RDF as the object of the tc:hasName
property (which incidentally does not HAVE to be a tn:TaxonName, since
tc:hasName does not have a defined range), at this point I guess the
uBio URI is the only choice since
there aren't ITIS http URIs (as far as I know). <br>
Steve<br>
<br>
Nicolson, David wrote:
<blockquote
cite="mid:9719DA81DAA0FF49A28BBC72821DCFA593CACA68B6@SI-MSEV03.US.SINET.SI.EDU"
type="cite">
<pre wrap="">Rich (et al.)... Just a quick comment re ITIS TSNs, since Rich posited:
=======================
My understanding (David N.: correct me if I'm wrong), is that all TSNs that correspond to "valid/accepted" names (where [taxonomic_units].[usage]='valid'|'accepted') essentially represent a taxon concept. The rest of the TSNs (where [taxonomic_units].[usage]='invalid'|'not accepted') represent a variety of things, ranging from different combinations to alternate spellings to subjective synonyms, each of which is referable to one of the "valid/accepted" names.
=======================
I would say "sort of".... The TSNs do not themselves correspond with much of anything other than a unique, persistent, non-intelligent identifier for a "scientific name" (I realize that begs your next question/point of what that term "means") record in the context of the ITIS data system. See this linked from the "About ITIS" page:
<a class="moz-txt-link-freetext"
href="http://www.itis.gov/pdf/faq_itis_tsn.pdf">http://www.itis.gov/pdf/faq_itis_tsn.pdf</a>
Re "Scientific Name", as you hopefully see in the above document, the term in ITIS generally corresponds to what I see from the ICBN use (Art. 16-24) and the ICZN use (Art. 4-5 in particular, as the "combination" formation, rather than the more atomized uses like "specific name" which is like "epithet"). There are of course other thing in ITIS with TSNs, like database artifacts, that are labeled as such and retained but hidden from most users to avoid confusion and not strand any user that might already have the TSN.
By way of an example of the use of "name" fields.... Just recently I was given a nice "finished" world dataset for a modest animal-family-that-shall-remain-nameless, and the "name" fields were in some cases just as ITIS uses them, and in others there were additional things like authorship and so on lumped in with the name parts in those fields, though there were no years provided even then. So, usable, but the amount of work to essentially re-parse the data was surprising for just a couple hundred names, and even then they were inconsistent and incomplete, so someone now has to go collect all the missing details and go over it all again, and it clearly needs some smoothing around the edges as well. That was for just 200+ names from a single source. Ugh, thanks....
As to the relationship to taxon concept, if you squinted your eyes "just so" you could qualify as Rich did above and suggest that those TSNs that happen to represent names with usage=valid/accepted (and preferably those with some level of verification indicated, vs. the legacy data we're still dealing with!) "essentially represent a taxon concept", but I don't really think that is appropriate at this point.... actually the closest thing in ITIS to a "taxon concept" would be certain entries in the reference_links table (the intersection between the scientific names entries and the reference entries), but even that is too abstract in my view. Since any number of references may be linked to a single TSN, that TSN won't necessarily yield something that maps to "a taxon concept" unless you're thinking "sensu ITIS v2011-05-31" or something of that ilk, which is I guess another way to think about it, with its own pros/cons.
And I agree with Rich's warnings of many pitfalls below (dragons and such).
I'll leave it there. Oops. So much for the "quick" comment....
Best,
Dave
David Nicolson
Data Development Coordinator, Integrated Taxonomic Information System
Biologist, USGS Core Science Systems, Biological Informatics Program
<a class="moz-txt-link-abbreviated" href="mailto:nicolsod@si.edu">nicolsod@si.edu</a> Office 202-633-2149 Fax 202-786-2934
<a class="moz-txt-link-freetext" href="http://www.itis.gov/">http://www.itis.gov/</a>
<a class="moz-txt-link-freetext" href="http://www.cbif.gc.ca/itis/">http://www.cbif.gc.ca/itis/</a>
"Nihil sumas necesse est..."
-----Original Message-----
From: Richard Pyle [<a class="moz-txt-link-freetext"
href="mailto:deepreef@bishopmuseum.org">mailto:deepreef@bishopmuseum.org</a>]
Sent: Friday, June 03, 2011 3:16 PM
To: 'Steven J. Baskauf'; 'Kevin Richards'
Cc: <a class="moz-txt-link-abbreviated"
href="mailto:tdwg-content@lists.tdwg.org">tdwg-content@lists.tdwg.org</a>; Orrell, Thomas; 'Alan J Hampson'; Nicolson, David; 'Gerald Guala'
Subject: RE: [tdwg-content] ITIS TSNID to uBio NamebankIDs mapping
Hi All,
I'm just catching up on email now, after a series of other work-related
obligations and virtual attendance at a cybertaxonomy/e-literature meeting
in Chicago this week. I do not now have time to review the entire thread,
so I'll jump into the stream with Steve's recent post.
</pre>
<blockquote type="cite">
<pre wrap="">I think that one reason why this question has been on my mind is that I've
</pre>
</blockquote>
<pre wrap=""><!---->been waiting for
</pre>
<blockquote type="cite">
<pre wrap="">GNUB (Global Name Use Bank) to come out.
</pre>
</blockquote>
<pre wrap=""><!---->
Just a quick update, due to budgetary woes in the U.S. Federal Government,
NSF funding for awarded proposals has been pushed every further back. If
I'm not mistaken, something like 18 months passed between proposal
submission and availability of funds for the BiSciCol grant, which our
institution was only able to (finally!) start processing within the past few
months. Why is this relevant to GNUB? Because the BiSciCol grant includes
the most substantial funding yet for implementation of GNUB (indeed, the
only funding for GNUB by name). The good news is that, now that funding is
in hand and money (finally) flowing, development & implementation of GNUB is
ramping up quickly. And the promise of more (and more substantial) funding
is just around the corner (watch this space).
</pre>
<blockquote type="cite">
<pre wrap="">I'm not really up on how it is going to work, but my impression is that it
</pre>
</blockquote>
<pre wrap=""><!---->was going
</pre>
<blockquote type="cite">
<pre wrap="">to be based on the Global Name Index (GNI) which was mentioned in that
</pre>
</blockquote>
<pre wrap=""><!---->earlier
</pre>
<blockquote type="cite">
<pre wrap="">January thread.
</pre>
</blockquote>
<pre wrap=""><!---->
Not exactly. GNI and GNUB represent two ends of a spectrum. GNI is at the
"minimal metadata/maximal content" end of the spectrum -- basically a
repository of any text-string purported to represent a taxon name that can
be linked via a resolvable identifier. GNUB is at the "richly
metadata'd/carefully curated" end of the spectrum, representing a highly
normalized structure with permanent resolvable GUIDs and the potential for
robust information/data services. In the vernacular, GNI is the "dirty
bucket", and GNUB is the "clean bucket". At the moment, the connection
between GNUB and GNI is unidirectional, in that the content of the
progenitor of GNUB has been indexed in GNI, but there is no mechanism (yet)
for GNI content to feed into GNUB. The reason for this is fairly
straightforward: it's very easy to flatten out normalized content into
simple text strings (GNUB-->GNI), but it's much more difficult (impossible?)
to migrate metadata-poor, moderately parsed content into a highly structured
system.
</pre>
<blockquote type="cite">
<pre wrap="">At that point, the GNI names didn't have any identifiers that were exposed
</pre>
</blockquote>
<pre wrap=""><!---->to
</pre>
<blockquote type="cite">
<pre wrap="">the public as permanent GUIDs. I'm assuming that if GNUB refers to GNI
</pre>
</blockquote>
<pre wrap=""><!---->names,
</pre>
<blockquote type="cite">
<pre wrap="">they will have some kind of identifiers. So if that happens how is the
</pre>
</blockquote>
<pre wrap=""><!---->GUID
</pre>
<blockquote type="cite">
<pre wrap="">recommendation 8 going to be followed? As Kevin said in
<a class="moz-txt-link-freetext"
href="http://lists.tdwg.org/pipermail/tdwg-content/2011-June/002499.html">http://lists.tdwg.org/pipermail/tdwg-content/2011-June/002499.html</a> "What I
</pre>
</blockquote>
<pre wrap=""><!---->take
</pre>
<blockquote type="cite">
<pre wrap="">from recommendation 8 of the GUID applicability guide ... is that if you
</pre>
</blockquote>
<pre wrap=""><!---->DON'T
</pre>
<blockquote type="cite">
<pre wrap="">already have a record in your own database for a taxon name/concept, then
reuse an existing one. " What we have here with GNI is a situation where
</pre>
</blockquote>
<pre wrap=""><!---->none
</pre>
<blockquote type="cite">
<pre wrap="">of the records have identifiers. In my mind, the "best practice"
</pre>
</blockquote>
<pre wrap=""><!---->according to
</pre>
<blockquote type="cite">
<pre wrap="">recommendation 8 would be for the GNI to reuse existing identifiers where
they exist and NOT make up new ones. This is a bit more complicated
</pre>
</blockquote>
<pre wrap=""><!---->because the
</pre>
<blockquote type="cite">
<pre wrap="">ITIS identifiers (which are in common use) don't have an http URI version
</pre>
</blockquote>
<pre wrap=""><!---->that is
</pre>
<blockquote type="cite">
<pre wrap="">resolvable, and while the uBio identifiers have a resolvable http URI,
</pre>
</blockquote>
<pre wrap=""><!---->it's in the
</pre>
<blockquote type="cite">
<pre wrap="">form of a proxied LSID, which I've already complained is very ugly. So
</pre>
</blockquote>
<pre wrap=""><!---->I'd like to
</pre>
<blockquote type="cite">
<pre wrap="">hear some ideas about how to have "reused" identifiers in the GNI.
</pre>
</blockquote>
<pre wrap=""><!---->
In terms of GUIDs, the objects in GNUB and the objects in GNI are not the
same, and therefore cannot share identifiers. The core object in GNI is a
text-string. Indeed, the text string itself can be the actual identifier,
because it *is* the thing being identified. In other words, because the
essential uniqueness of an instance (record) in GNI by definition *is* the
text string (i.e., the series of UTF-8-encoded characters), then that text
string represents a perfectly suitable unique identifier. There is no need
to generate a surrogate identifier like an integer number or UUID or LSID or
whatever (except, perhaps, for internal use as a primary key for joining
tables; but those identifiers need not/should not be exposed to the outside
world).
By contrast, the core object in GNUB is a taxon name usage instance -- which
is a purely abstract notion of the usage of a taxon name within some
documentation source (like a publication). In this case, the text-string
name is merely a property of the GUID-identified object, and would be an
extremely BAD choice to use as a unique identifier. This is why GNUB needs
to generate a unique identifier to represent this core data object. The
form that identifier takes (UUID, LSID, integer, DOI, whatever) from the
perspective of the end user should be completely irrelevant, because the
user should rarely (if ever) see it, and should certainly *never* be in a
position to type it on a keyboard (we can discuss the appearance of ZooBank
LSIDs on printed pages separately). All that matters is that it is
persistent, globally unique identifier that can be used to cross-link
information and can be conveniently resolved to the metadata of the object
it represents.
But the point is, recommendation 8 of the GUID applicability guide is not
being violated in the context of GNI and GNUB.
The real problem in all of this is the inconsistent meaning people apply to
the notion of a "taxon name". In GNI-space, the name is simply a text
string. In GNUB-space, the "name-object" is a code-compliant Protonym that
serves to cross-link Name-usages to each other. ITIS is different still.
My understanding (David N.: correct me if I'm wrong), is that all TSNs that
correspond to "valid/accepted" names (where
[taxonomic_units].[usage]='valid'|'accepted') essentially represent a taxon
concept. The rest of the TSNs (where
[taxonomic_units].[usage]='invalid'|'not accepted') represent a variety of
things, ranging from different combinations to alternate spellings to
subjective synonyms, each of which is referable to one of the
"valid/accepted" names. CoL uses names as proxies to taxon concepts (not
sure how they handle synonyms vs. misspellings, etc.) And there are other
variations as well -- to most botanists, "Aus bus L." and "Xus bus (L.)
Smith" represent "different names", whereas to most zoologists (who would
not bother to include the "Smith"), regard them as the "different
combinations of the same name" (zoologists are less consistent than
botanists in this regard).
The point is, this inconsistency and heterogeneity of what is meant by a
"name" in taxonomy is, in my opinion, the single GREATEST obstacle in
achieving informatics harmony among biodiversity datsets.
</pre>
<blockquote type="cite">
<pre wrap="">One thing that comes to my mind would be to have a "domain name" like
<a class="moz-txt-link-rfc2396E" href="http://purl.org/gni/">"http://purl.org/gni/"</a> or <a
class="moz-txt-link-rfc2396E" href="http://purl.org/tn/">"http://purl.org/tn/"</a> ("tn" for "taxon name")
</pre>
</blockquote>
<pre wrap=""><!---->and
</pre>
<blockquote type="cite">
<pre wrap="">to follow it with a namespace/id combination similar to what is done with
</pre>
</blockquote>
<pre wrap=""><!---->lsids.
</pre>
<blockquote type="cite">
<pre wrap="">So for example "itis/19408" and "ubio/448439" could be appended,
creating <a class="moz-txt-link-freetext"
href="http://purl.org/gni/itis/19408">http://purl.org/gni/itis/19408</a> and
</pre>
</blockquote>
<pre wrap=""><!----><a class="moz-txt-link-freetext"
href="http://purl.org/gni/ubio/448439">http://purl.org/gni/ubio/448439</a> for "
</pre>
<blockquote type="cite">
<pre wrap="">Quercus rubra L." Both URIs could point to the same RDF and that RDF
</pre>
</blockquote>
<pre wrap=""><!---->could
</pre>
<blockquote type="cite">
<pre wrap="">indicate that the two identifiers are owl:sameAs .
</pre>
</blockquote>
<pre wrap=""><!---->
This syntax is basically what ZooBank does (and GNUB will do), within their
own domain name. But I like the idea of a common URL domain that allows
these qualified identifiers to be appended.
The real problem is what you describe next:
</pre>
<blockquote type="cite">
<pre wrap="">I realize from what Bob Morris has cautioned in the past that there are
</pre>
</blockquote>
<pre wrap=""><!---->problems
</pre>
<blockquote type="cite">
<pre wrap="">with owl:sameAs when the two things aren't actually the same thing
(e.g. if the uBio ID refers to a name string only but the ITIS TSN refers
</pre>
</blockquote>
<pre wrap=""><!---->to the name
</pre>
<blockquote type="cite">
<pre wrap="">plus an "accepted" status and a relationship to parent taxa).
</pre>
</blockquote>
<pre wrap=""><!---->
Do NOT underestimate the significance of this point.
</pre>
<blockquote type="cite">
<pre wrap="">However, if there were an understanding that the GNI only refers to name
</pre>
</blockquote>
<pre wrap=""><!---->strings,
</pre>
<blockquote type="cite">
<pre wrap="">then one could still refer to <a
class="moz-txt-link-freetext" href="http://purl.org/gni/itis/19408">http://purl.org/gni/itis/19408</a> as an
</pre>
</blockquote>
<pre wrap=""><!---->identifier for the
</pre>
<blockquote type="cite">
<pre wrap="">name string of the thing (whatever it is) that is referred to by an ITIS
</pre>
</blockquote>
<pre wrap=""><!---->TSN of 19408.
Here be dragons -- for lots of reasons. At this point, you might as well
just do a text-string match on the name. The problem is, you'll miss the
match if authorship is not identical, but you risk homonymy mis-match if
authorship is not included.
</pre>
<blockquote type="cite">
<pre wrap="">I have no idea whether this would be a good idea or not, but I was really
</pre>
</blockquote>
<pre wrap=""><!---->cringing
</pre>
<blockquote type="cite">
<pre wrap="">to think about 19 million newly minted UUIDs appended to
</pre>
</blockquote>
<pre wrap=""><!----><a class="moz-txt-link-rfc2396E"
href="http://gni.globalnames.org/">"http://gni.globalnames.org/"</a>
</pre>
<blockquote type="cite">
<pre wrap="">and figuring out how to connect those horrid things to the names and ITIS
</pre>
</blockquote>
<pre wrap=""><!---->TSNs
</pre>
<blockquote type="cite">
<pre wrap="">that I'm already using. I think that I said this before, but using the
</pre>
</blockquote>
<pre wrap=""><!---->purl.org domain
</pre>
<blockquote type="cite">
<pre wrap="">rather than one like <a class="moz-txt-link-freetext"
href="http://gni.globalnames.org/">http://gni.globalnames.org/</a> would in the future allow
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
<blockquote type="cite">
<pre wrap="">somebody else to take over management of providing the metadata when the
GUIDs are resolved without having to deal with issues of who "owns" the
</pre>
</blockquote>
<pre wrap=""><!---->domain name.
As I said before, I think it's perfectly fine to generate UUIDs for internal
purposes within GNI for varius performance reasons (or whatever), but I
don't think it's wise to expose those UUIDs externally. Because the
uniqueness of a GNI record *is* the text string, then it makes more sense to
me to simply use the text string. However, that only works for
GNI/uBio/NameBank, where the essence of the record *is* the text string.
It's a non-starter for other datasets like GNUB, ITIS, CoL, and most others,
where the essence of the record is something altogether different.
Aloha,
Rich
Richard L. Pyle, PhD
Database Coordinator for Natural Sciences
Associate Zoologist in Ichthyology
Dive Safety Officer
Department of Natural Sciences, Bishop Museum
1525 Bernice St., Honolulu, HI 96817
Ph: (808)848-4115, Fax: (808)847-8252
email: <a class="moz-txt-link-abbreviated"
href="mailto:deepreef@bishopmuseum.org">deepreef@bishopmuseum.org</a>
<a class="moz-txt-link-freetext"
href="http://hbs.bishopmuseum.org/staff/pylerichard.html">http://hbs.bishopmuseum.org/staff/pylerichard.html</a>
.
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Steven J. Baskauf, Ph.D., Senior Lecturer
Vanderbilt University Dept. of Biological Sciences
postal mail address:
VU Station B 351634
Nashville, TN 37235-1634, U.S.A.
delivery address:
2125 Stevenson Center
1161 21st Ave., S.
Nashville, TN 37235
office: 2128 Stevenson Center
phone: (615) 343-4582, fax: (615) 343-6707
<a class="moz-txt-link-freetext" href="http://bioimages.vanderbilt.edu">http://bioimages.vanderbilt.edu</a>
</pre>
</body>
</html>