Taxon debate synthesis?

[Kennedy, Jessie]

Another quick reply re this thread...

One GUID system for Name Usages - why stop there - why not one GUID
system for anything? We are drawing arbitrary lines in trying to scope
what should or should not be encompassed in this GUID system. 
Why are we doing this? I would say to make it easier to use and refer to
taxon names, concepts, observations, general usages etc. consistently so
that the biologists can do better science. So what do biologists need to
know - the main thing (IMO) is what they are talking about so that when
they communicate electronically references are more meaningful/accurate.

I would've thought that they would want to know that if they get a GUID
for a concept then they aren't using a name or vice versa. 

One GUID system I think will encourage people to duplicate effort and
publish GUIDs for the sake of showing they've done something because
that's the easy bit. We should encourage one GUID for one thing be that
a concept or name or whatever rather than a GUID for every
representation of every electronic version of a record representing one
thing (I know this will be hard but we should work towards that
otherwise we're wasting people's time and money)

I agree from an implementation point of view one GUID system is easier
but from a user of the system I'm not so convinced or form an
implementer of a system trying to deal with all of the different types
of things you might get returned when all you want are names or
whatever.

> 
> >
> > I would point out that within the "TaxonName" flavor, there may be
> > "subflavors" like "Basionym", "New Combination", and "Orthographic
> > Variant" -- just as within the TaxonConcept flavor there are
> > "Original",
> > "Revision", "Nominal", etc. subflavors. (Apologies for my
Amerikanized
> > spelling...)
> >
> 
> Before we have a flurry of name flavours (yuck), I'd suggest that many
> of these "flavours" are really relationships between names, e.g.
> "Physeter catadon" is a misspelling of "Physeter catodon". Hence, I'd
> argue for having GUIDs for these two name strings, and in the metadata
> for one name have something like
> 
> <isMisspellingOf rdf:resource="urn:lsid:authority:namespace:123" />
> 
> Hence, I think before we embark on adding complexity, why not have
> GUIDs for names and then specify relationships between these names?
> This is what I've been doing with the LSIDs we serve here.
> 
And of course this is what TCS has done in modelling the TaxonNames
element. There are explicit relationships you can have between names
such as misspelling of or basionymof. These relationships can't exist
between taxon concepts just as a name being included in another name
can't exist between taxon Names.

One of the reasons we were asked in TCS to split Taxon Names form Taxon
concepts.


> We could do with an ontology for these relationships so that, for
> example, if somebody asks for the synonyms of name "x", and two names
> are linked by the relationship "isBasionymOf" we recover that
> relationship (in other words, our tools know that 'isBasionymOf" is a
> kind of synonym).
> 
> Again, let's try and keep things simple.

I'm not convinced at the end of the day this would be simple but....

> 
> This leads to a much more general topic, but I think if we adopt RDF
> for our metadata we gain a lot of query and inference tools "for
free."
> GUIDs by themselves are boring, it's the metadata that matters.
> 
> >
> > My general feeling is that most of the useful information is
metadata,
> > the
> > only candidates for data (in my mind) being the literal text string
> > (NameString), a ref pointer to a defined Documentation instance (if
> > any),
> > and perhaps position information (e.g. page) within the
Documentation
> > instance.  All of these might be intially recorded in error, but
could
> > be
> > corrected via the LSID revision id (version).
> 
> I think everything about a name probably is metadata, and doing this
> opens up the possibility of doing useful things with that metadata
(see
> above). In the LSID stuff we've been doing at Glasgow the only time we
> provide data is if we are serving images, in which case it makes sense
> to serve a stream of bytes (e.g., a TIFF image). In one sense, data
> isn't that interesting (or, put another way in many cases it requires
a
> person to make sense of it, whereas computers can handle metadata).


Am I right in thinking that the proposal means that all of the data for
taxon names or concepts or observations or whatever might be construed
as name usages will be described as meta-data for each GUID?
To me this meta-data is what we've been describing as data when
modelling TCS. 
I agree GUIDs aren't interesting in themselves but I'm not convinced
that computers can handle meta-data.....of the complexity we'd need to
model names, concepts, observations etc. I'd be interested in seeing
evidence of this - again I could be wrong......

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.