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

[Paul Kirk]

mycologist have lived with ambiregnal names since the codes were written wrt the protozoan fungi (slime moulds), strange thing is the only significant impact has been at suprageneric ranks were alternate suffixess on the same stem for familes, orders etc. have been adopted by some groups of workers - a botanical tradition and style has been used for names at the rank of genus and below. The Index of Fungi - IndexFungorum continues to index these names.

________________________________

From: Richard Pyle [mailto:deepreef at bishopmuseum.org]
Sent: Tue 22/03/2005 18:43
To: tcs-lc at ecoinformatics.org
Subject: RE: [tcs-lc] Re: Question about XML attribute vs. element



> 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. 


_______________________________________________ 
tcs-lc mailing list 
tcs-lc at ecoinformatics.org 
http://www.ecoinformatics.org/mailman/listinfo/tcs-lc 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 8806 bytes
Desc: not available
Url : http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/tcs-lc/attachments/20050322/84e2cc2f/attachment.bin