[tcs-lc] Unnecessary vernacular relationship types?

[Richard Pyle]

If the concrete proposal is to evaluate the enumerated list of
RelationshipTypes within the ratified TCS v1, and this is not outside the
realm of potentially "minor" changes, then I would like to take one last
opportunity to articulate the broader point I have been trying to make.

Since the "vernacular" issue seems to have had the most traction in terms of
mutual understanding, I will begin there.

The initial problem I raised was that the existing "is vernacular for" and
"has vernacular" seems to imply that relationships between scientific-name
Concepts and vernacular-name concepts can only be established on the basis
of the "is congruent" RelationshipType.  Maybe this is not the case -- maybe
the RelationshipType "is vernacular for" spans "congruent", "includes", "is
included in", and "overlaps", without specifying anything other than "Not
Excludes".  But if we wanted to be anal about this, we really should define
a series of vernacular RelationshipTypes:

"is vernacular for" [congruent]
"has vernacular" [congruent]
"is included in venracular"
"includes vernacular"
"overlaps with vernacular"
"excludes venracular"

So...why don't we define all of these RelationshipTypes as well, to allow
the full scope of options for mapping vernacular names to scientific names?
The answer, I believe, is that doing so would be silly.  The reason it would
be silly is what James already pointed out: that the nature of relationships
between venracular names and scientific names can be easily identified by
examining the mandatory TaxonConcept/Name at scientific attribute of each
TaxonConcept involved in a Relationship.  If one TC has "True" for this
attribute, and the other has "False" for this attribute, then we
intrinsically know we have the equivalent of a mapping of a scientific name
to a vernacular name (by whatever standard RelationshipType is indicated),
so we don't need the full set of "vernacular" equivalents as listed above.
Indeed, we don't even need the existing "is vernacular for" / "has
vernacular" RelationshipTypes.

This is the same logic I have used to argue that "Is Parent Of" and "Is
Child Of" RelationshipTypes are equally redundant.  The main difference in
this case is that NameObject/Rank is not mandatory (minOcc=0). [By the
way....I thought we all agreed that TaxonConcept/Rank was to be eliminated
in TCS v1.0, since it is unambiguously a property of a NameObject, and not a
TaxonConcept???? Maybe this is the root of the communication problem we are
now having!]  But my argument is that if either of two TaxonConcepts is
linked to a NameObject that lacks a Rank (or is not linked to a NameObject
at all), then "Is Parent" and "Is Child" have no meaning distinct from
"Includes/IsIncludedIn".

Xianhua wrote:

> There is big difference between IsParentOf and Includes.
> First of all, they define the inter-concept relationship
> in different senses. “IsParentOf” defines the relationship
> in the  nomenclatural hierarchy, while “Includes” in terms
> of inclusiveness.

Right -- exactly: *nomenclatural* hierarchy.  Such hierarchy can only be
established in the context of Ranks. Without the context of Ranks, there is
no difference between "IsParentOf" and "Includes".

> Secondly, they are not interchangeable. “A IsParentOf B”
> can imply “A Includes B”, but “A Includes B” does not
> necessarily  mean “A IsParentOf B”.

Agreed -- but the only sense in which "IsParentOf" is not equivalent to
"Includes", is in the sense of Name-Name relationships.  And that really
underscores my biggest fundamental problem with
TaxonConcept/Relationships -- which is the confounding of Name-Name
RelationshipTypes with Concept-Concept RelationshipTypes.

> Let’s go one step further. Given 2 TaxonConcepts, different
> people may see different TYPE of relationships with different
> semantics. Before we go to define any actual relationship,
> it could be helpful to categorize possible relationships
> into some groups according to their semantics, such as,
>  Nomenclatural relationship: the relationship of a concept
>    to another in the nomenclatural hierarchy, including parent,
>    synonym and homonym.
>  Operational Relationship: the operation that generates one
>    concept from others, e.g. splitting an existing concept
>    into two or moving a concept from its current parent to
>    another.
>  Phylogenetic relationship: the relative position of a concept
>    to another in the evolutionary chain.
>  Logic relationship: the relationship between concepts in term
>    of their inclusiveness, such as greater than, less than,
>    equal or overlap.
>
> Above is just a show-my-bricks-to-get-your-jade type of example.
> I do not think it is good to cook all possible relationships in
> one pot. There might be some better recipe.

As far as I can tell, we share a common understanding of the problem.  It's
just not completely clear whether we both see the same path to a solution.
Unfortunately, I think the real solution involves "non-minor" changes of the
sort that cannot be implemented before next week.

However, depending on whether the scope of items contained in the
RelationshipType enumeration is subject to modification prior to finalizing
v1.00, I'm simply requesting that if "is vernacular for"/"has vernacular"
Types are on the table for removal from the ratified schema, that we also
very carefully consider some of the other RelationshipTypes.

I also have some final thoughts on the "Not" RelationshipTypes, which I will
summarize in a separate post.

Aloha,
Rich



-----Original Message-----
From: tcs-lc-bounces at ecoinformatics.org
[mailto:tcs-lc-bounces at ecoinformatics.org]On Behalf Of Roger Hyam
Sent: Friday, September 23, 2005 4:28 AM
To: Nozomi Ytow
Cc: tcs-lc at ecoinformatics.org
Subject: Re: [tcs-lc] Unnecessary vernacular relationship types?


This seems like a concrete proposal so I have raised it as an issue 047 for
possible modification of schema before V1.0 - depending on discussion about
implications.

Roger


Nozomi Ytow wrote:
Rich wrote:


I agree that "is vernacular for" and "has vernacular" RelationshipTypes seem
to imply only congruent relationships -- maybe that is your original point?
If so, I agree this is not good.


The vernacular relationship pair are unnecessary because scientific
attribute of TaxonConcept/Name became mandatory in v1.00.   If
TaxonConcept/Name at scientific have different values in TaxonConcept
elements linked by a relationship-ish element then it means the
relationship vernacular one.  I should realise it when discussed about
scientific and language, but I didn't realise relationship enumeration
in that time... sigh.

JMS
_______________________________________________
Tcs-lc mailing list
Tcs-lc at ecoinformatics.org
http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/tcs-lc




--

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