<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Excerpts from what Richard Pyle wrote and responses:
<blockquote cite="mid:000901cdcd48$53a98390$fafc8ab0$@bishopmuseum.org"
 type="cite">
  <pre wrap="">
I'm not saying this ever will happen, or even should happen.  But we've
developed the data model such that it *could* happen, if it turns out to be
a useful mechanism for mapping specimens to published taxon concepts.

  </pre>
  <blockquote type="cite">
    <pre wrap="">As so often is the case, I think the problem here boils down to
identifiers and the metadata that we associate with them.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Absolutely!!! This is often not intuitive stuff, so the trickey part is
getting people to apply identifiers and cross-link them in an appropriate
and consistent way.
  </pre>
</blockquote>
As a person who isn't really sure if he believes in RDF (and the
co-convener of the RDF Task Group) and as a person who finds this whole
conversation more annoying than about anything else he can think of
(but who is actually trying to walk this walk with his metadata), I'm
saying that we are there.&nbsp; HTTP URIs are not THE way to create
identifiers but they are A way to create identifiers that demonstrably
work.&nbsp; RDF is not THE way to cross link identifiers but they are A way
to cross link identifiers.&nbsp; History is full of examples where a way of
doing things that wasn't the best won out because
it was there when needed.&nbsp; (I'm thinking typewriter keyboard.)<br>
<blockquote cite="mid:000901cdcd48$53a98390$fafc8ab0$@bishopmuseum.org"
 type="cite">
  <pre wrap="">  </pre>
  <blockquote type="cite">
    <pre wrap="">Let's say in the real-life example above, somebody (we
can say GNUB) assigns a persistent identifier (perhaps a
URI constructed from an opaque UUID) to "Juncus diffusissimus Buckl. sec
    </pre>
  </blockquote>
  <pre wrap=""><!---->L. Urbatsch 2009".
  </pre>
  <blockquote type="cite">
    <pre wrap="">We could say with an rdf:type statement that the resource
identified by the URI is a TNU.  We can give that resource a
tc:hasName property linking it to the name which is
represented by the string "Juncus diffusissimus Buckl.".
(I'm not sure what property we use to say that L. Urbatch made the
    </pre>
  </blockquote>
  <pre wrap=""><!---->assertion).

I'm not sure how you would do it in RDF, but if it's any help the relevant
DwC term is taxon:nameAccordingToID.
  </pre>
</blockquote>
This is a major part of why I'm interested in this conversation.&nbsp; All
of the dwc: "ID" terms are flawed for use in RDF for technical reasons
that I've described elsewhere (see
<a class="moz-txt-link-freetext" href="http://code.google.com/p/tdwg-rdf/wiki/Beginners4Vocabularies#4.6._The_Darwin_Core_vocabulary_normative_definition_as_RDF">http://code.google.com/p/tdwg-rdf/wiki/Beginners4Vocabularies#4.6._The_Darwin_Core_vocabulary_normative_definition_as_RDF</a>&nbsp;
<a class="moz-txt-link-freetext" href="http://code.google.com/p/tdwg-rdf/wiki/DublinCore#1.3.2.4._dcterms:identifier_(AC)">http://code.google.com/p/tdwg-rdf/wiki/DublinCore#1.3.2.4._dcterms:identifier_(AC)</a>
and
<a class="moz-txt-link-freetext" href="http://code.google.com/p/tdwg-rdf/wiki/DublinCore#2.4._Possible_courses_of_action_where_users_may_be_inclined_to_u">http://code.google.com/p/tdwg-rdf/wiki/DublinCore#2.4._Possible_courses_of_action_where_users_may_be_inclined_to_u</a>
if you care about this).&nbsp; I believe that tc:accordingTo would be a
fairly exact equivalent to dwc:nameAccordingToID which does not have
the subproperty problems the DwC ID terms have in RDF.&nbsp; So the question
in my mind (and I think a question posed explicitly earlier in this
thread) is whether enough of the technical stuff you want to do with
TNUs can be done with the TDWG Taxon Concept ontology which is based on
a ratified TDWG standard (TCS). &nbsp;
<blockquote cite="mid:000901cdcd48$53a98390$fafc8ab0$@bishopmuseum.org"
 type="cite">
  <pre wrap="">It's certainly part of the metadata for the TNU itself:

There is a TNU for diffusissimus within the Reference of Buckl.  This is the
original description of the epithet, so it is also the Protonym for
diffusissimus.  There is also a TNU for the genus name Juncus as used within
the Reference of Buckl.  If, in the same publication, Buckl. Also
established that genus, then the genus would also be the Protonym TNU.
However, the genus Juncus was established by L., so there is another TNU for
Juncus that is the protonym (Juncus L.), and the TNU for the usage of Juncus
within Buckl. Links to the TNU of Juncus L. (the Protonym).

So, that's three TNUs:
1. Juncus L. sec. L. (Protonym for the genus Juncus)
2. Juncus L. sec. Buckl. (links to 1 as ProtonymID)
3. diffusissimus Buckl. sec. Buckl. (Protonym for the species diffusissimus,
links to 2 as parent)

There are also two more TNUs linked to the Urbatsch 2009 publication:
4. Juncus L. sec. Urbatsch (links to 1 as ProtonymID)
5. diffusissimus Buckl. sec. Urbatsch (links to 3 as ProtonymID, and to 4 as
parent)

  </pre>
  <blockquote type="cite">
    <pre wrap="">Now let's say that L. Urbatsch publishes a paper describing in detail her
concept of Juncus diffusissimus Buckl.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Do you mean the 2009 paper of "Juncus diffusissimus Buckl. sec L. Urbatsch
2009"? (In which case we have the TNUs as 4 &amp; 5).... or do you mean a later
paper (2010)?  In which case we'd need two more TNUs. Is the "2009" thing a
specimen determination, or a publication?  It doesn't matter -- I just want
to make sure I'm following your example correctly.
  </pre>
</blockquote>
The 2009 "thing" is something that L. Urbatsh had in his head - the
idea of how he thought the name "Juncus diffusissimus Buckl." should be
applied to real organisms and the specimens that come from them.&nbsp; We
don't know what that idea is but presumably he had one and we could
assign a persistent identifier to it and describe it using the string
"Juncus diffusissimus Buckl. sec L. Urbatsch 2009".&nbsp;&nbsp; I was thinking
that was what you meant by TNU.&nbsp; Whether or not it is better to
proliferate a bunch of additional TNU instances, assign them their own
identifiers, and relate them to each other is a technical detail that
as an end user I'm happy to let you take care of within your GNUB
system.&nbsp; End users want a persistent identifier of some sort to link
identification instances to.&nbsp; They will hopefully find it through a
user-friendly interface that hides the ugly details you are describing
here.<br>
<br>
[some quotes omitted for brevity]<br>
<blockquote cite="mid:000901cdcd48$53a98390$fafc8ab0$@bishopmuseum.org"
 type="cite">
  <pre wrap="">
  </pre>
  <blockquote type="cite">
    <pre wrap="">The point I'm trying to make is that as long as this "thing"
that we are variously calling "taxon name usage", "taxon concept",
"shallow taxonomic concept", or "deep taxonomic concept"
can be assigned an identifier, what really matters is the metadata
we associate with it, not really what we call it.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Absolutely!  With emphasis on "really matters".  It's certainly important to
mint persistent identifiers, but it's equally (more?) important to make sure
we understand the "thing" the identifier represents.  We have a pretty
stable &amp; solid definition of a TNU, that has emerged form many NOMINA
meetings over a number of years.  What I don't think has been done yet, is
any real analysis of whether the appropriate subset of TNUs accompanied by a
robust concept definition *are* the concepts (i.e., the TNU GUID is the
concept GUID); or whether there should be a separate GUID minted explicitly
for the concept, which then links back to the TNU GUID as it's "definition"
or "source" (or whatever).  I can see it working both ways.
  </pre>
</blockquote>
I looked at the TDWG Taxon Concept ontology (see
<a class="moz-txt-link-freetext" href="http://code.google.com/p/tdwg-ontology/source/browse/trunk/ontology/voc/TaxonConcept.owl">http://code.google.com/p/tdwg-ontology/source/browse/trunk/ontology/voc/TaxonConcept.owl</a>
) and came up with the following scenario.&nbsp; Let's say that I assign a
persistent identifier [URI1] to the TNU we are talking about here,
"Juncus diffusissimus Buckl. sec L. Urbatsch 2009" and that I'm right
that by TNU we mean the idea that Lowell Urbatch had in his head about
how he meant to&nbsp; (sorry to drag him into this randomly - I actually
don't know him).&nbsp; <br>
We can assign a tc:accordingTo property to [URI1] with the object of
that property being some kind of resource whose metadata says that
Lowell Urbatcsh used the name in some sense known to him in 2009.&nbsp; (We
could work out the details of how one would write that metadata but
there probably is enough stuff in the Dublin Core and FOAF vocabularies
to do it.&nbsp; I think later in your email you said GNUB calls it a
"Reference".) &nbsp; Now let's say that in 2012 I call him on the phone and
say "hey Lowell, what taxonomic treatment were you thinking about in
2009 when you annotated that specimen in the NLU herbarium with barcode
LSU00000428?" and he says "Gleason and Cronquist, 1991".&nbsp; I have two
choices:<br>
1.&nbsp; add&nbsp; a tc:describedBy property to the metadata for [URI1] with the
value urn:isbn:0893273651 (a persistent URI representing Gleason and
Cronquist 1991) and "promote" the resource identified by [URI1] from
generic TNU to "deeper" taxonomic concept.<br>
2. create a different [URI2] which has a property/value pair of
tc:describedBy urn:isbn:0893273651 , then somehow relate the royal URI2
taxonomic concept to the lowly URI1 generic TNU.&nbsp; <br>
<br>
If we use owl:sameAs to relate the two&nbsp; instances (i.e. assert [URI2]
owl:sameAs [URI1] ) then there is no advantage to option two.&nbsp; All
statements made about [URI1] would apply to [URI2] and vice-versa.&nbsp; All
we would be accomplishing is doubling the number of triples that we
have to keep track of.&nbsp; The question is whether this would result in
"bad" or "silly" statements (the essence&nbsp; of Bob Morris' objection to
owl:sameAs, I think).&nbsp; If so, then we need some kind of new term to
relate royal Taxon Concepts ("deep" taxonomic concepts) to lowly&nbsp;
generic TNUs ("shallow" taxonomic concepts).&nbsp; I don't think such a term
exists at the moment.<br>
<br>
The advantage of choice 1 is that we have off-the-shelf technology (the
TDWG Taxon Concept ontology based on a ratified TDWG standard, TCS).&nbsp;
If we go with choice 2 (and don't use owl:sameAs to relate the two
URIs), then we doom ourselves to another five+ years of thrashing out
some new vocabulary or ontology for relating TNUs to Taxon Concepts.&nbsp;
So here where we would be if we went with choice 1:<br>
<br>
1. The rdf:type of the "thing" is tc:Taxon or tc:TaxonConcept .&nbsp; The
ontology declares them to be equivalent classes.&nbsp; <br>
2. The minimal requirement for a tc:Taxon is to have a persistent
identifier and a name associated with it, either through tc:nameString
literal or better yet a tc:hasName property whose value is a persistent
URI that provides more extensive metadata than a string.&nbsp; uBio comes to
mind here as a giant source of name strings with assigned persistent
identifiers.&nbsp; A tc:Taxon instance having only name information would be
a nominal taxon - an undesirable but probably common circumstance.<br>
3. If the tc:Taxon instance has a tc:accordingTo property, it is
elevated to TNU status because we can know who used the name and when
if we investigate of the object of the tc:accordingTo property
further.&nbsp; Maybe we can learn more about this kind of tc:Taxon instance
later, but in most cases probably not.<br>
4. If the tc:Taxon instance has a tc:describedBy property, then it is
elevated to full taxonomic concept status because it would be related
to the persistent identifier of a published taxonomic treatment.&nbsp; One
could then theoretically discover all kinds of cool relationships to
other full-blown concepts using the tools that Nico and Rich are going
to develop.&nbsp; <br>
<br>
One could create a Venn diagram showing the subset relationships of
these three levels of tc:Taxon.&nbsp; If it made Rich feel better, he could
mint a class URI for the deep taxonomic concepts which could be used in
rdf:type statements in addition to the basic rdf:type of tc:Taxon .&nbsp; <br>
<br>
I see this as a way to make rapid progress on this front by leveraging
work which has already been completed and accepted by TDWG but not
really implemented.&nbsp; The TDWG Taxon Concept ontology and TCS may not do
everything that people want as far as allowing one to define all of the
set relationships required to do the fancy stuff.&nbsp; But I don't see why
that can't be added in a TCS 2.0 that is backwardly compatible with TCS
1.2 .&nbsp; <br>
<br>
I will defend my repeated references to HTTP URIs and RDF by saying
that this email is being posted to the TDWG RDF group list but also
because the ratified standard for GUIDs (see
<a class="moz-txt-link-freetext" href="http://bioimages.vanderbilt.edu/pages/guid-applicability-final-2011-01.pdf">http://bioimages.vanderbilt.edu/pages/guid-applicability-final-2011-01.pdf</a>)
says that persistent identifiers must be HTTP proxied (recommendation
2) and that they should resolve to provide RDF/XML (recommendation
10).&nbsp;&nbsp; Having not yet achieved the degree of cynicism attained by Rod
Page about people actually following TDWG standards, I still believe
that we should try to follow them.&nbsp; Or else just stop wasting time on
this...<br>
<br>
Steve<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>