Taxon debate synthesis?

[Steven Perry]

Hi Jessie & Ricardo,

As an implementer (not a domain scientist), I've been thinking about
some of these same issues while designing and prototyping DiGIR 2.  I'll
place my comments in-line:


Kennedy, Jessie wrote:

>Hi Ricardo
>
>
>
>>    I think we should really have one GUID system for anything.
>>    For one, a single GUID system will favor integration within and
>>across domains. For example, if you get a GUID somewhere, you don't
>>
>>
>need
>
>
>>to figure out which GUID system you use to resolve it, you just
>>
>>
>resolve
>
>
>>it within the one GUID system and get metadata describing the object.
>>Can be a taxon concept, which can have GUIDs linking it to specimens
>>
>>
>and
>
>
>>observation data, which in turn can be resolved using the same
>>architecture.
>>
>>
>
>I agree this is easier for us to implement - I think I mentioned that
>but I don't think that's always the right reason for doing something.
>
>
>
I agree with both of you.  One reason for implementing a single GUID
system is ease of resolution, but it's not the only reason.  As I see
it, the alternative, which provides multiple GUID systems, each
obligated by a social contract to provide GUIDs that are restricted to a
certain type of data object, does not really provide any guarantee that
you know what type of object you will get when you resolve a GUID.
Inside of a GUID system, it is quite difficult to enforce that a certain
form of GUID will resolve to a certain type of data object.  Even with a
centralized service problem cases can occur.  People can publish GUIDs
for the wrong type of object, either by mistake or through malice.
However, even if this is prevented though technological means, there is
another difficult case.

This case occurs when one part of the community needs to extend an
existing schema or ontology.  Even if they design a clean extension of
an existing class whose instances can polymorphically appear to be
instances of the existing base class, this new class of data objects
will not have exactly the same type as the existing class.  If the
authority that is responsible for serving instances of the base class
refuses to allow the extension, the portion of the community that
requires it will fork and start their own  authority despite the fact
that the two classes of data object are related.  If the central
authority allows the extension, its implicit contract with clients that
it serves only known types of objects will be broken.

So, it may always be the case, even with several authorities that
attempt to serve only objects of specific types, that a piece of client
software will have to gracefully handle data objects of unknown types.
In my opinion, the best way to handle the problem is to place the burden
of figuring out what type a data object has or what it means
semantically on the client software, not on the GUID infrastructure.
The client software will have to understand the data objects anyway, and
the first step in this process is usually figuring out what type a data
object has.

>>    Second, I tend to think that such a system will work better if the
>>assigning authorities are descentralized, i.e. agents are free to
>>
>>
>assign
>
>
>>GUIDs to anything.
>>
>>
>
>The only issue here - and I don't think there is an easy answer - is the
>trade off between easy issuing of GUIDs and difficulty of knowing what
>you get back from them, what you can do with them and which GUIDs are of
>real value....I guess what you're saying is let the users decide that
>even if they don't really know what the issues are. I'd like to for
>example decide that if IPNI issue TaxonNames GUIDs then I can decide
>wholesale to accept that they've done a good job and know they are
>names, know they are not concepts, know what I will get and therefore
>what I can do with them - I don't really want to have to figure that out
>somehow at run-time.
>
>
>
I think that you bring up several different issues here. In my mind the
issue of what kind of data object you get back when you resolve a GUID
(and therefore what you can do with it) is orthogonal to the issues data
quality and trust.  The first issue can be solved with technology, the
second issue can be addressed with technology (but never truly solved)
and the third depends on human intervention.

The most easily addressable issue is knowing how to understand what you
get back when you resolve a GUID.  My only comment here is that it's
likely that the end user will not be dealing directly with the resolved
data objects.  Instead I imagine that they'll be working with a piece of
client software that understands a set of ontologies (and can perhaps
dynamically fetch new ones).  This client software will have to
understand the data objects semantically and give the user some options
on how to resolve GUIDs that are referenced in a resolved data object,
how to merge many objects into a single graph, and how to display or
output these data objects in a form that is useful.

This has some serious implications for what type of data representation
system we use.  Building a client like this that can deal with data
objects described with XML Schema would be difficult (perhaps even
impossible).  I agree with Roderic Page that RDF makes the problem
easier to solve.  While this is supposed to be a discussion of GUIDs,
you can't cleanly separate the GUID mechanism from the data
representation system (because design decisions taken in one system
constrain the design of the other).

The second issue, whether or not a resolved data object is of real value
can be addressed in several ways.  First it needs to be syntactically
valid and semantically meaningful to be of real use.  Syntactic validity
is easy to test but depends on how we decide to represent data objects.
The constraint that data objects be semantically meaningful can be
partially addressed if we use real ontologies that can be reasoned over,
but depends in part upon how crazy we get with our ontologies.  It is
possible to "semantically validate" data objects against an ontology and
this service should be part of client software.

The third issue, trust, is interesting.  My feeling is that there will
be two different ways that an end user can get data objects and that
trust will work differently for the two methods.  The first method will
be by using some kind of portal or search engine.  If a domain scientist
is interested in finding some taxonomic concepts so she can use them in
her work, she's not going to start by using a GUID resolution system.
Instead, she'll work with a portal or piece of client software, that has
it's own user interface or protocol and perhaps some algorithm for
selecting the most likely concepts that match some search constraints.
She will query this service and examine the results to select one or
more taxonomic concepts.  From that point on, she can refer to them in
her work using GUIDs.  In this case trust is evaluated by her during her
selection of a service to query and her selection of the specific taxon
concepts that seem to make sense.

The second method of working with GUIDs occurs when a domain scientist
resolves a GUID to get back an object (through the use of client
software).  In this case she can decide to trust the result based not
just on well formedness and whether or not the data object seems to make
sense, but also based on who created the data object.  Information on
the ownership of data objects could be represented in the metadata about
those objects or it could be represented in the GUID itself (as in the
authority part of an LSID).  But if there is only one central issuing
authority and metadata about creator or owner is not stored with each
object, then it's hard to resolve the trust issue.

>>    What controls the caos in this case are the metadata services. You
>>can issue GUIDs right and left, but then what will add value to them
>>
>>
>is
>
>
>>how you cross link them and maybe more importantly, how the community
>>uses the objects you issued GUIDs for (again this relates to cross
>>linking objects).
>>
>>
>
>I can understand this to some extent but (possibly because of my
>ignorance) can't quite see how this will work. I'm a little confused
>about what say IPNI or TROPICOS would do here - I'm imagining they would
>issues GUIDs for what they have in their databases....how would this
>work and how and who would cross link their GUIDs. What would they issue
>GUIDs for? How would we refer to their concepts or names? What would we
>get returned I'm not sure from this proposal.
>TCS relies on lots of cross linking but all of the cross linking for one
>concept is encapsulated within the one concept (and thereby GUID).  So
>for example we differentiate between relationships which were mentioned
>in the definition of that concept between the concept and other
>concepts, and relationships by others regarding that concept which are
>opinions of others and not part of the definition of the concept as
>defined. How would we do that?
>
>
>>    Third, if you want, you still can have a centralized metadata
>>service that works like an authority saying which taxon GUIDs are
>>important.
>>    I just don't think you can enforce data correctness at the issuing
>>authority level.
>>
>>
>
>Yes if I was clear about what I was getting if I resolved a taxon GUID.
>I'm still not entirely clear what we're getting back.
>I agree you can't enforce correctness at the issuing authority level but
>I think you can set up agreements as to what your protocol for
>publishing is and what you will do with your objects that you have
>assigned GUIDs to etc.
>
>Can anyone tell me come to think about it what we are planning on
>providing here? If anyone can issue GUIDs (I guess using their own GUID
>server) for any taxon thing - or really anything that anybody wants to
>consider a taxon thing. What "extra" value are we talking about
>providing?
>
>
>
>
>>    Regarding your comment that computers can't handle metadata, I
>>
>>
>think
>
>
>>we need to explore that a little bit more with examples. Could some of
>>us in the group present more concrete examples on how something like
>>that would be done? I think that if we define one or more ontologies
>>(i.e. a classification scheme for things getting GUIDs) computers can
>>than say: I know what the class this object belongs to, it's a
>>NameUsage, or a TissueFromSpecimen, and act upon it. If the system
>>doesn't know what kind of object that is, it can just ignore it or try
>>to render it using a xslt stylesheet that can be used to displays that
>>content to the user (if that's available).
>>
>>
>>
>I guess what I was trying to get at here is - does the metadata tell me
>what kind of object I'm getting or does it contain the data (or at least
>some of the data) that I've been thinking is the values for the concept.
>I'm confused about that after reading some of the posts.
>
>I don't want to stop us progressing but I want to be sure that where
>we're going is going to add some value to what is out there already.
>
>
>

In my mind, GUIDs are simply pointers to data objects.  The agreements
should be about how data objects are represented in the community. In
other words, what ontologies are used and how these ontologies model the
semantic properties of data objects and the relationships between
different types of data objects.  How it works exactly depends upon what
GUID scheme we select and how we decide to represent knowledge in the
community.

Here's an example of one way of doing things.  I apologize in advance
for going into depth, but I think it's required in order to illustrate
what I'm talking about.

If we select LSIDs as the GUID mechanism and RDF-Schema or OWL
ontologies as the knowledge representation layer, then LSIDs will
resolve to chunks of RDF (metadata, since the data portion of LSIDs
should be reserved for holding complex binary objects like images or
sound files that can't be "understood").  Each chunk of RDF represents
one or more data objects that should be instances of some ontological
class.  Because every data object, no matter what it is, is represented
in the same way (RDF), the client software only has to parse one format
(and does not have to know about countless XML Schema and how to parse
and understand instances documents from them).  There are already many
APIs available for working with RDF (we use Jena
http://jena.sourceforge.net in DiGIR2).

Inside a chunk of RDF, a single data object is identified by a resource
URI (in our case this would be the LSID URN).  The representation of a
data object takes the form of a series of assertions about that object.
These assertions are statements in the form of subject, predicate, and
object.  So, if the data object represents a taxonomic name, that name's
LSID is the subject of any assertion about it.  The predicate would be
some URI that uniquely identifies a property of the class that the data
object belongs to, for instance it's name or it's relationship to an
another data object.  Finally the object of the statement is some
value.  What makes RDF powerful and flexible is that objects (values)
can be other resources.  So, it's possible to represent a data object
like this:

Assertion 1:
    Subject: <urn:lsid:authority:namespace:123>
    Predicate: <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
    Object: <http://tdwg.org/ontologies/tcs/3.0#taxonomicName>

Which says that the data object identified by the LSID
urn:lsid:authority:namespace:123 is an instance of the class
taxonomicName which is defined in the OWL ontology whose namespace is
http://tdwg.org/ontologies/tcs/3.0

Assertion 2:
    Subject: <urn:lsid:authority:namespace:123>
    Predicate: <http://tdwg.org/ontologies/tcs/3.0#nameString>
    Object: "Physeter catodon"

Which says that the object identified by the LSID
urn:lsid:authority:namespace:123 has a property called nameString (which
is defined in the OWL ontology with the namespace
http://tdwg.org/ontologies/tcs/3.0) and it's value is set to the string
Physeter catodon"  (Forgive me if this is not correct TCS, I'm trying to
keep it simple).

Assertion 3:
    Subject: <urn:lsid:authority:namespace:123>
    Predicate: <http://tdwg.org/ontologies/tcs/3.0#isBasionymOf>
    Object: <urn:lsid:authority:namespace:256>

Which says that the object identified by the LSID
urn:lsid:authority:namespace:123 has a property called isBasionymOf
(which is defined in the OWL ontology with the namespace
http://tdwg.org/ontologies/tcs/3.0) and it's value is set to the data
object identified by the LSID urn:lsid:authority:namespace:256.

So, as soon as you resolve urn:lsid:authority:namespace:123, you know
that it is a taxonomic name, that is has some properties (like
nameString) and that it is related so some other data object in a well
defined way.  The beautiful thing is that even if the piece of software
that has to resolve and understand an LSID doesn't know what type of
data object it is (this would be the case if assertion 1 was missing),
it can still know some things about it and how it relates to other
things (because it would recognize the predicates).  It is also possible
for the client software to fetch the original ontology and make further
inferences from it.

I've tried to give a concrete example above of how it might work with
LSIDs and RDF.  It's a rather simple example and does not cover all
cases (such as whether urn:lsid:authority:namespace:256 should be
automatically resolved as part of the resolution of
urn:lsid:authority:namespace:123), but it's a start.

RDF with LSIDs is not the only option, but I think it provides a great
deal of power and flexibility.  While it places a large burden on the
client software to be able to "understand" data objects, it also uses a
well defined, standard set of technologies to do so.  It makes it easier
to develop ontologies from the bottom up (which is quite hard to do with
XML Schema because they have to import each other and because of other
technological difficulties posed by substitution groups and other Schema
mechanisms) and allows the client the chance to do something with data
objects, even if it only partially understands them.

It's useful to discuss GUID mechanisms independently of how data objects
are represented, but at some point (in the client software) these issues
are coupled and must be dealt with.  Otherwise it's difficult to
envision how the choice of a GUID scheme will constrain the choice of a
data object representation system, and vice versa.

-Steve


>Thanks,
>
>Jessie
>
>This message is intended for the addressee(s) only and should not be read, copied or disclosed to anyone else outwith the University without the permission of the sender.
>It is your responsibility to ensure that this message and any attachments are scanned for viruses or other defects. Napier University does not accept liability for any loss
>or damage which may result from this email or any attachment, or for errors or omissions arising after it was sent. Email is not a secure medium. Email entering the
>University's system is subject to routine monitoring and filtering by the University.
>
>