[tcs-lc] Names as Objects

Richard Pyle deepreef at bishopmuseum.org
Thu Mar 3 19:16:23 PST 2005


To preface this note, I want to make it clear that I am not necessarily
advocating the alternative approach to the basic TCS structure that I
describe below.  I'm looking at this more as a "What if" thought experiment,
with the hope that maybe we can more clearly understand where we agree, and
where we need to focus more discussion. Perhaps this already has been
discussed on a Wiki somewhere, and perhaps this has already been thought
through and discarded.  But I want to put this out there on this list
anyway, if for no other reason than to serve as a "straw man" to help me
understand why it is seen as such a bad thing if names are treated as
distinct objects from concepts. I'll try to keep this as concise as
possible.

Right now, TCS is structure like something this (highly simplified):

<DataSet>
  <Vouchers>
    [...instances of Voucher objects formatted to some schema]
  </Vouchers>
  <Publications>
    [...instances of Publication objects formatted to some schema]
  </Publications>
  <TaxonConcepts>
    <TaxonConcept>
	<Name>
	  <NameSimple>
	    [simple rendering of name]
	  </NameSimple>
        <NameDetailed>
	    [...entire embeded Nomenclatural schema]
        </NameDetailed>
	</Name>
	<AccordingTo>
	  <AccordingToSimple>
	    [simple rendering of AccordingTo source]
	  </AccordingToSimple>
	  <AccordingToDetailed>
	    [...various simple elements and a reference to a Publication object]
	  </AccordingToDetailed>
	</AccordingTo>
	<Relationships>
	  [...references to other TaxonConcept objects]
	</Relationships>
	<SpecimenCircumscription>
	  [...references to Voucher objects]
	</SpecimenCircumscription>
    <TaxonConcept>
    [...more instances of TaxonConcept objects]
  </TaxonConcepts>
  <RelationshipAssertions>
    [...etc.]
  </RelationshipAssertions>
</DataSet>

Obviously I've simplified and/or omitted a bunch of stuff, but the main
point is that the "Nomenclatural schema" (ABCD Names in v085a; possibly to
be replaced by LC) is embedded within the TaxonConcept instances, such that
the name elements amount to properties of a TaxonConcept, rather than as
separate objects by themselves.  This is in contrast to Vouchers and
Publications, which are objects that exist separately from TaxonConcepts,
but are referenced (via UIDs, preumably) from within TaxonConcepts.

I have been championing the perspective that "Name Objects" exist as
distinct entities from "Concept Objects".  If my perspective bears out, then
we should be able to rearrange the above schema into something like this:

<DataSet>
  <Vouchers>
    [...instances of Voucher objects formatted to some schema]
  </Vouchers>
  <Publications>
    [...instances of Publication objects formatted to some schema]
  </Publications>
  <TaxonNames>
    [...instances of TaxonName objects formatted to some schema, like LC]
  </TaxonNames>
  <TaxonConcepts>
    <TaxonConcept>
	<Name>
	  <NameSimple>
	    [simple rendering of name]
	  </NameSimple>
        <NameDetailed>
	    [...various simple elements and a reference to TaxonName object(s)]
        </NameDetailed>
	</Name>
	<AccordingTo>
	  <AccordingToSimple>
	    [simple rendering of AccordingTo source]
	  </AccordingToSimple>
	  <AccordingToDetailed>
	    [...various simple elements and a reference to a Publication object]
	  </AccordingToDetailed>
	</AccordingTo>
	<Relationships>
	  [...references to other TaxonConcept objects]
	</Relationships>
	<SpecimenCircumscription>
	  [...references to Vouchers]
	</SpecimenCircumscription>
    <TaxonConcept>
    [...more instances of TaxonConcept objects]
  </TaxonConcepts>
  <RelationshipAssertions>
    [...etc.]
  </RelationshipAssertions>
</DataSet>

The only difference is that the entire nomenclatural schema has been pulled
out from within TaxonConcepts, and given its own top-level structure just
like Publications and Vouchers.  Also, the scope of "type" of Relationships
would be more restrictive in the latter scenario -- excluding those that
involve concept-less nomenclatural relationships between names.

As I said, I'm not trying to suggest (necessarily) that this would be a
better way, ANd I don't want to get bogged down too much in details about
specific elements. But if this general/gross approach (treating names as
distinct top-level objects from Concepts) has already been considered and
rejected, I would appreciate it if someone could explain to me why it was
rejected.

I think this approach would be more appealing from the LC prespective,
because it would allow a "clean" package of name-only data along the lines
of:

<DataSet>
  <Vouchers>
    [Type specimens]
  </Vouchers>
  <Publications>
    [Nomenclaturally relevant publications]
  </Publications>
  <TaxonNames>
    [Full-blown Name data, with references to publications and type specimen
vouchers]
  </TaxonNames>
</DataSet>

I can immediately see several concerns from the TCS perspective, such as the
possible encouragement of attaching specimen identifications directly to
Names (without passing through a concept), and perhaps some confusion about
what sorts or information appropriately belongs within
TaxonConcept/Relationshops, vs. within the Names.  I'm not sure what impact
it would have on "Nominal" and "Original" concepts (especially in terms of
the appearnce of redundant information).  But what other reasons make this
alternative approach suboptimal?

On a sort of related question, would it be worth considering an "<Agents>"
top-level element & simple schema?  That would allow UID reference to Agent
objects from within Vouchers (as collectors, etc.), from within Publications
(as authors), from within LC (as name authors, when different from authors
of original description publications), from within TaxonConcept/AccordingTo
(as AccordingTo source), and from within RelationshipAssertion/AccordingTo
(same).

Aloha,
Rich

Richard L. Pyle, PhD
Ichthyology, Bishop Museum
1525 Bernice St., Honolulu, HI 96817
Ph: (808)848-4115, Fax: (808)847-8252
email: deepreef at bishopmuseum.org
http://www.bishopmuseum.org/bishop/HBS/pylerichard.html






More information about the Tcs-lc mailing list