Message 2005-12-0012: Re: Stormbergia dangershoeki, new Early Jurassic ornithischian from South Africa

Mon, 10 Oct 2005 03:09:45 -0700 (PDT)

[Previous by date - Re: Stormbergia dangershoeki, new Early Jurassic ornithischian from South Africa]
[Next by date - Re: Stormbergia dangershoeki, new Early Jurassic ornithischian from South Africa]
[Previous by subject - Re: Stormbergia dangershoeki, new Early Jurassic ornithischian from South Africa]
[Next by subject - Re: Stormbergia dangershoeki, new Early Jurassic ornithischian from South Africa]

Date: Mon, 10 Oct 2005 03:09:45 -0700 (PDT)
From: [unknown]
To: Mike Taylor <mike@miketaylor.org.uk>
Cc: keesey@gmail.com, dinosaur@usc.edu, phylocode@ouvaxa.cats.ohiou.e=
Subject: Re: Stormbergia dangershoeki, new Early Jurassic ornithischian from South Africa

I am coming in to the discussion late, so please forgive me if these =
points have already been made.

> Is it just me, or does anyone else feel uncomfortable about the ide=
a
> that, once the PhyloCode is implemented, there will be a much stron=
ger
> tendency to respect strict priority in the definitions of clades, s=
o
> that we don't have the kinds of options that Mike and Tim are argui=
ng
> about here?
>
> I love the fact that the PhyloCode infrastructure includes an on-li=
ne
> register of published clade names and definitions, but I find mysel=
f
> wondering whether it would be better if the register listed _all_
> published definitions of eacdh name rather than just the first (and
> only, if the recommendations are followed).

It depends on what you want to use it for, of course, but purely from=
 a knowledge-representation point of view, I would argue for having a=
ll the published names listed.

If the PhyloCode is to eventually serve as the basis for computerized=
 knowledge bases and query engines on these materials, then it will n=
ot be able to integrate all the different sources if it knows only of=
 one published name--it will only have access to the sources that use=
 that one name.

To take an analogy from comparative anatomy, the organ in the mouse w=
hich is called the "coagulating gland" is also called the "anterior p=
rostate". Despite the different names, however, it is the same organ.=
 So you would reasonably expect that if you were to do a literature s=
earch on either term in PubMed, you would get the same corpus of lite=
rature.

However, a search on "coagulating gland" (as of just now) returns 240=
 hits. A search on "anterior prostate" returns 91 hits. And that 91 i=
s not even a true subset of the 240, since a search on ("anterior pro=
state" OR "coagulating gland") returns 315 hits--in other words, the =
first set of articles and the second set overlap so little as to be a=
lmost disjunct. That means that the comprehensiveness of the literatu=
re returned by PubMed _for the same organ_ is dependent on the arbitr=
ary choice of term used.

I do not think that you want the PhyloCode to share in the same kind =
of arbitraryness as a basis for computer applications on its appropri=
ate corpus of literature. You are facing an uphill battle for accepta=
nce anyway, and if you force designers of knowledge-base and query ap=
plications to have to go to some great effort to accommodate the Phyl=
oCode to gain access to all the corpora of literature that uses the o=
ld names, I seriously doubt that they will take that effort.

If, on the other hand, you build this support in right from the begin=
ning by accommodating all the published names (and you can privilege =
some and deprecate others; all names do not have to be created equal)=
, by making it immediately useful to serve in aligning the old names =
in the corpora, you will take a huge step toward the acceptance and w=
ider usage of the PhyloCode as people see its usefulness for aligning=
 different knowledge bases.

Ravensara S. Travillian <ravensar@u.washington.edu>


  

Feedback to <mike@indexdata.com> is welcome!