[Tcs-lc] Human Readable - the thread formally known as 'Nameof NomenCode'

[Richard Pyle]

Jessie wrote:

> If it is as say a revision of a genus then each species is a
> "child of" the genus being revised. (of course one could interpret
> this to mean the genus includes the species but as Bob says
> this is implied - the relationship would be child of - agree
> with Bob's interpretation)

Can someone explain to me the difference between "is child of" and
"includes"?  Does the difference have something to do with nomenclature &
rank (e.g., one species concept can include another species concept, but a
concept can only be the child of another concept that is assigned to a
higher-rank name)?

If it is a distinction that exists only in the context of nomenclature, then
is it a name-name relationship, or a concept-concept relationship?

> If someone comes along and defines a new speices for a genus
> and are saying the genus is the "parent of" the species. This
> in no way redefines the genus as described by the original author
> - so there should be no cascading.

Agreed.

> However someone working on the genus in future would want to
> consider the species that was defined to have the genus as
> it's parent so they might in their revision of the genus
> redefine it to include that species.

Hmmm....Not sure I follow.  Consider:

Aus Smith 1950 SEC. Smith 1950
Aus bus Smith 1950 SEC. Smith 1950

Aus bus Smith 1950 SEC. Jones 1970
Aus dus Jones 1970 SEC. Jones 1970

Given this information, we don't automatically know what the relationship of
Aus Smith 1950 SEC. Jones 1970 is to Aus Smith 1950 SEC. Smith 1950

Perhaps this is the case:

	([Aus bus SEC. Jones]+[Aus dus SEC. Jones])=[Aus bus SEC. Smith]

...in which case [Aus SEC. Jones]=[Aus Sec. Smith]

Or, it might be this:

	[Aus bus SEC. Jones]=[Aus bus SEC. Smith]

...in which case [Aus SEC. Jones]>[Aus Sec. Smith]

Clearly in the latter case, we would need to define a new TaxonConcept
instance for [Aus SEC. Jones].  But what about the former case?  I assume
that, if we have confidence of the congruency between the two meanings of
"Aus" (e.g., Jones specifically said so), then we do not need to define a
new TaxonConcept instance for [Aus SEC. Jones].  But what if we're not so
certain?  It seems to me like we should define a new TaxonConcept instance
for [Aus SEC. Jones] just in case, so that later authors have the option of
creating RelationshipAssertions that either define congruency, or some other
relationshiptype.

> Of course the author might have explicitly said they were redefining
> the genus by accepting the previous definition (and all of its species
> as is) and adding a new species in which case we would have a revision
> of the genus and the relationship could then in this case be "child of".

Hmmmm....I don't get this bit, in realtion to your previous comments.


> This is why we need different types of relationships with different
> semantics to allow us to choose to traverse them or not in dffierent
> situations.

Maybe it would help me understand the role of "is parent of/is child of"
RelationshipTypes if I understood how the semantics differ from "includes/is
included in".

> If I have have a revision of a family F1 according to X say and produce
> a hierarchy of the genera it contains (g1..G3) and for each of these the
> species they contain (s1-s3),(s4-s7) (s8). If someone,Y, later came along
> and said that they had found a new species s9 and placed it in G3 then
> this would not change the definition of G3 or F1 as defined by X.

I think we are (or should all) be clear on this.  But the tricky part (to
me) is knowing the relationship between [G3 SEC. Y] and [G3 SEC. X]. Might
be congruent; might be "includes".


> well it depends on whether we are modelling how taxonomy should be done
> or how it has been done.

These don't have to be mutually exclusive.

> If we want to cover best practice for futrue and deal with legacy data
> and approaches then we can't write rules expressing how it should've
> been done.

Agreed!

Aloha,
Rich