[tcs-lc] Name-Name Relationships vs. Concept-Concept relationships

Kennedy, Jessie J.Kennedy at napier.ac.uk
Tue Sep 20 08:59:34 PDT 2005


> 

> 1) Name-Name Relationships vs. Concept-Concept relationships.

> In TCS 1.00, a few Name-Name relationships are explicitly embedded
within

> the NameObject container: SpellingCorrectionOf, Basionym, BasedOn,

> ConservedAgainst, LaterHomonymOf, NomenNovumFor, and certain implied
or

> explicit Name-Name links within CanonicalName and Typification.  But
other

> Name-Name relationships are (presumably) accomodated within

> TaxonConcept/Relationships.  I presume this because the annotation for
the

> "Relationships" element says: "Stores explicit, taxonomic and

> nomenclatural

> relationships that are part of the original concept definition." I am

> uncomfortable with the way that different Name-Name relationships are

> represented in different ways, and I had expressed this discomfort

> throughout the TCS/LC discussions of yore.  My discomfort is at
several

> levels, both fundamental (e.g., Why shouldn't Name-Name relationships
be

> captured in a similar generic structure in the way that
Concept-Concept

> relationships are captured?; Why are some relationships stored in

> NameObject, and others in TaxonConcept?), and specific (e.g.,
shouldn't

> "IsLaterHomonymOf" be "IsJuniorHomonymOf"?). Which leads me to:

> 

 

We had this discussion in St Petersburg but for the benefit of those who
couldn't make it (we missed you....)

 

Name-Name relationships are explicit for 2 reasons (not necessarily good
design reasons!)

1.	We are trying to separate names from concepts and not to mix the
two so one of my concessions to moving names to top level objects was
that we would allow names to be related to concepts in any way other
than by allowing a concept to point to a name. The easiest way of doing
this was to be explicit about the relationships allowed between names.
So if you have relationships other than those listed then you were
wandering into concept territory and maybe you should be dealing with
concepts rather than names. I believe from discussion on tcs-lc and from
discussion with Roger who had private conversations with some folks that
those listed covered what the nomenclaturists required. If this is not
the case then we need to know. Roger can confirm  (or deny this) I also
believe that some of the relationship types you list Rich are subsumed
by those we offer again Roger can confirm.
2.	The second reason is that it looks more like the original
Linnean core representation that everyone seemed to like...and just for
good measure - related to point one it's easier to add new instances to
an enumerated list than to change the schema structure so I thought that
we would be able to keep the separation between names and concepts more
easily if we did it like this. Concept relationships in the other hand
are more numerous abd possible more likely to change although some
thought has gone into this list by various people in TCS and SEEK and
based on what is commonly used by others.

 

So in principal I agree it would be nice to have the same generic
structure but I also had these reasons. If and until TDWG applies
general design approaches applicable to all the standards regarding
these sorts of issues I'm reluctant to change it.

 

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. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/tcs-lc/attachments/20050920/0246f249/attachment.htm


More information about the Tcs-lc mailing list