[tcs-lc] Re: Question about XML attribute vs. element

Richard Pyle deepreef at bishopmuseum.org
Tue Mar 22 10:43:48 PST 2005


> I don't think I follow the arguments here, but my naive head is breaking
> over the discussion when understood in naive terms. I _thought_ it was
> ok to understand that if two uses of a name circumscribed two different
> sets of organisms then the name  belongs to two different concepts,

Yes.

> and
> I _thought_ that there is no single organism that can be assigned to a
> class named by both ICZN and ICBN (which I understand to mean there is
> no such thing as something that is both a plant and an animal).

No.  This is the (weird) situation that James and I are discussing.  Certian
Protista have been assigned the same name both as a plant, and as an animal.
These two names are "ambiregnal" names. Thus, one original concept
circumscription is assigned one name-string (name-literal), but that one
name-string is subject to both ICBN and ICZN Code rules.  In the simplest
view, this could be treated in LC as one original concept, with one name.
However, because the name is governed by two codes, as time goes on the
Botanical version of that name may follow a different nomenclatural path
than the zoological version of that name (due to different rules being
applied).  To accomodate these different nomenclatural paths, it is useful
to treat them as two separate "names", one governed by ICBN and one governed
by ICZN. Thus, one concept with two names (even though those two names begin
as the same name-literal).

However, TCS in its current form (as I understand it) does not accomodate
more than one name per concept, so the only way to handle this situation is
to establish two original concepts, defined as congruent with each other,
one of which points to the ICBN version of the name, and the other pointing
to the ICZN version of the name.

A Google search on "ambiregnal" may be helpful; the first hit is the LC Wiki
discussion initiated by James:
http://www.soc.napier.ac.uk/tdwg/index.php?pagename=AmbiregnalTaxon&version=
10

> [All of this seems independent of the question of attribute vs. element.
> For an xs:string that question is entirely a matter of taste. As a
> software engineer, my taste is usually to have similar things being
> treated similarly. That would argue for leaving NameSimple as an
> element, even though it is very simple compared to ScientificName. If
> you don't believe that NameSimple and ScientificName are closely
> related, then you might argue on some other grounds that an attribute is
> preferable.]

Where it's relevant is if, in the case of ambiregnal names, it is decided
that the best way to handle them is to have one original concept, with one
name, and that name applies to two different codes.  In that scenario, I
gather it is not kosher in XML to have:

<Name type="scientific" NomenCode="ICBN" NomenCode="ICBN">
  <NameSimple>Ambiregnalus namus</NameSimple>
</Name>

Thus, we would need something like:

<Name type="scientific">
  <NomenCode>ICBN</NomenCode>
  <NomenCode>ICZN</NomenCode>
  <NameSimple>Ambiregnalus namus</NameSimple>
</Name>

...or whatever.

The point is, *if* a solution for ambiregnal names is to treat them as one
name with two Codes, then it would be better for NomenCode to be an element,
rather than an attribute.

However, the outcome of the discussion James and I just had was that we both
agree that ambiregnal names should be treated as two separate "Name"
instances (even though they initially share the same name-literal, and apply
to the same original concept circumscription), thus preserving the the 1:1
relationship between name instance and NomenCode value.

The second half of the discussion between James and I was with regard to how
to represent the concept: either as one concept instance with two names, or
two congruent concept instances, each with only one name.

So....though I understand why NameSimple is best treated as an element,
rather than an attribute; what do you think about NomenCode?  I'm leaning
toward attribute, because it seems to me something that has a short,
well-defined enumeration, and is fundamental to a name object (more like a
"type").

Rich

P.S. Lest one thinks that ambiregnal names are not worth the effort to track
as two names under separate Codes, consider the situation if PhyloCode is
enacted.  Thousands of names will be adopted (initially) by the PhyloCode,
and each will have a separate fate (both nomenclaturally, and
circumscription) from the Linnean-Code-governed version of the name.





More information about the Tcs-lc mailing list