Taxon debate synthesis?

Roger Hyam roger at TDWG.ORG
Wed Nov 16 11:03:24 CET 2005


I think Ricardo has hit it the nail on the head in his recent post.

Here is a possible solution that might just work!

   1. Only one GUID system.
   2. For taxon stuff we call these NameUsage GUIDs
   3. NameUsage GUIDs come in different 'flavours' - probably identified
      by the metadata returned.
   4. Some flavours may be TaxonName, TaxonConcept and NameOccurrence
   5. We have an ontology that defines the types of NameUsage GUID.
   6. The ontology can evolve through time catering for different needs.

To restate what Ricardo suggest this would entail:

   1. Identifiers deliver you to objects (where feasible).
   2. Identifiers deliver you to object metadata.
   3. Each object should wear its own identifier (desirable).
   4. Identifiers are issued in a decentralized manner, i.e., by
      independent agents.
   5. Ids identify digital objects, not physical ones.
   6. more...

Questions this raises for me are:

   1. Do we have a single managed ontology for all TDWG GUIDs i.e. we
      have a single ontology to manage different types of specimen GUID
      and different types of NameUsage GUID. This looks like a central
      ontology for taxonomic object classes and may take the debate
      outside the GUID discussions into general architecture.
   2. Can you tell by looking at a GUID what it's class is. i.e. do we
      embed the class name in the LSID namespace. This would be useful
      for debugging and human readability but is really bad practice as
      IDs should be opaque (people should not start parsing pointers for
      purposes other than resolving them).
   3. If we use LSIDs what do we include in the 'data' returned and what
      in the metadata returned? I believe the metadata can change but
      data can't so we may want to put our metadata as the LSID data (I
      don't think an object class should change - I may be wrong)

There are probably other questions.

This may be a fruitful way forward.

Roger

--

-------------------------------------
 Roger Hyam
 Technical Architect
 Taxonomic Databases Working Group
-------------------------------------
 http://www.tdwg.org
 roger at tdwg.org
 +44 1578 722782
-------------------------------------


--------------080701020708090106080105
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!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">
<br>
I think Ricardo has hit it the nail on the head in his recent post.<br>
<br>
Here is a possible solution that might just work!<br>
<ol>
  <li>Only one GUID system.</li>
  <li>For taxon stuff we call these NameUsage GUIDs<br>
  </li>
  <li>NameUsage GUIDs come in different 'flavours' - probably
identified by the metadata returned.</li>
  <li>Some flavours may be TaxonName, TaxonConcept and NameOccurrence <br>
  </li>
  <li>We have an ontology that defines the types of NameUsage GUID.</li>
  <li>The ontology can evolve through time catering for different needs.</li>
</ol>
To restate what Ricardo suggest this would entail:<br>
<ol>
  <li>Identifiers deliver you to objects (where feasible).
  </li>
  <li>Identifiers deliver you to object metadata.
  </li>
  <li>Each object should wear its own identifier (desirable).
  </li>
  <li>Identifiers are issued in a decentralized manner, i.e., by
independent agents.
  </li>
  <li>Ids identify digital objects, not physical ones.</li>
  <li>more...</li>
</ol>
Questions this raises for me are:<br>
<ol>
  <li>Do we have a single managed ontology for all TDWG GUIDs i.e. we
have a single ontology to manage different types of specimen GUID and
different types of NameUsage GUID. This looks like a central ontology
for taxonomic object classes and may take the debate outside the GUID
discussions into general architecture.<br>
  </li>
  <li>Can you tell by looking at a GUID what it's class is. i.e. do we
embed the class name in the LSID namespace. This would be useful for
debugging and human readability but is really bad practice as IDs
should be opaque (people should not start parsing pointers for purposes
other than resolving them).<br>
  </li>
  <li>If we use LSIDs what do we include in the 'data' returned and
what in the metadata returned? I believe the metadata can change but
data can't so we may want to put our metadata as the LSID data (I don't
think an object class should change - I may be wrong)<br>
  </li>
</ol>
There are probably other questions.<br>
<br>
This may be a fruitful way forward.<br>
<br>
Roger<br>
<br>
<pre class="moz-signature" cols="72">--

-------------------------------------
 Roger Hyam
 Technical Architect
 Taxonomic Databases Working Group
-------------------------------------
 <a class="moz-txt-link-freetext" href="http://www.tdwg.org">http://www.tdwg.org</a>
 <a class="moz-txt-link-abbreviated" href="mailto:roger at tdwg.org">roger at tdwg.org</a>
 +44 1578 722782
-------------------------------------
</pre>
</body>
</html>


More information about the tdwg-tag mailing list