[tcs-lc] You don't need embedded names to do concepts

Richard Pyle deepreef at bishopmuseum.org
Wed Mar 9 13:23:58 PST 2005


> I have been talking to a few people off list and doing some thinking and
> I would like to return to a point that was made earlier when Rich
> proposed (but denies it :) having a top level names element within the
> schema.

For the record, here are the first two sentences of the email in which I
"allegedly" :-) proposed names as top-level objects:

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

Actually, James Ytow should get credit (or blame...) for propsing it,
because he discussed it in Christchurch.

> The question is whether we embed names in TaxonConcepts or whether we
> have separate top level element called 'Nomenclature' or similar which
> contains name objects and just have a pointer to them from
> TaxonConcepts. Briefly this is "NamesAsObjects" vs "NamesEmbedded" debate.

I don't think they are necessarily mutually exclusive perspectives.  I think
that the schema example I posted represents both.  The real distinction, I
think, is between "NamesAsObjectsThatAnXMLSchemaCanEnforce", and
"NamesTreatedAsObjectsButEmbeddedWithinOtherObjectsAndExpressedAsTypesOfThos
eOtherObjects".

> My opinion has moved to favouring NamesAsObjects. Here is the straw that
> broke the camel's back for me.

Yikes! :-)

> Imagine I want to pass a TaxonConcept from my system to your system. I
> have the circumscription here in my field guide. I have been using it
> during my survey of Wonderland.
>
> Under the current TCS NamesEmbedded model I either:
>
> a) Pass the complete name details, i.e. the canonical name the
> unstructured name the canonical author string, the micro ref, the
> pointer to the reference etc. embedded in the TaxonConcept.
>
> OR
>
> b) I pass a pointer to the 'Original' TaxonConcept the name was used by
> (I can't point to the name itself). You can then retrieve the Original
> TaxonConcept and ignore any circumscription details that come with that
> object because they are irrelevant.

OR

c) you pass a pointer to the 'Nominal' TaxonConcept instance for the name,
which includes within a a special-case set of elements to capture the
name-object data.  That way, you don't have to ignore anything (or, more
practically, you don't have to parse out the bits you can ignore from the
bits you don't want to ignore).

> Clearly I don't want to pass the full name details every time I pass a
> concept but I would like to give  you the ability to expand on the
> details I do send so it is most sensible to do b.
>
> Making you retrieve the Original concept circumscription (which neither
> of us may be interested in at all) and then discard it is a little
> contrived to put it mildly.

*EXACTLY* why (well, one of the main reasons, anyway) I think a "Nominal"
Concept instance (redefined the way have) serves as the optimal bearer of
nonmenclatural-object information.  You get the name data, you get the
implied "fuzzy" concept scope that a Nominal Concept was intended to
represent, and you don't have to discard anything.

> So what I would do as an implementor is
> provide a SOAP or digger call, getScientificName(), that just returns
> the name part of the original concept. I'll put together an XML Schema
> to express this and hey presto we have a Name as an object - which is
> what we are trying to avoid with having names embedded.
>
> Exactly the same process occurs for retrieving basionym data.

...not to mention a host of other name-name relationship information.

> Since this straw broke my camel's back some other straws have come to my
> notice such as where you link to type specimens that aren't part of you
> taxon circumscription - but I won't go into them just now.

I think I went into it in the schema I sent, but here's a synopsis.  Looking
at "Set 2" of what I sent, the Nominal Concept (name-bearing) instance would
include within NameDetailed something to the effect of what I represented as
"PrimaryTypeSpecimen".  Every non-nominal Concept instance would thus have
access to the type specimen information (via a pointer to the corresponding
Nominal Concept instance), without it necessarily being a part of the
non-Nominal concept circumscription itself (though surely it would be
*implied* as being contained within the defined concept circumscription!)

In cases where the non-Nominal concept circumscription explicitly cites the
type specimen as a voucher representing part of the definition of the
non-Nominal concept, there would be a direct link to that specimen among the
SpecimenCircumscription instances.  This might seem like a duplication of
information, but it really is not.  Within the context of the Nominal
Concept pointer to the specimen (inside PrimaryTypeSpecimen), the
information represents "this name is typified by".  Within the context of
the non-Nominal Concept pointer to the same specimen, the information
represents "this specimen is explicitly included with this concept".  Two
different pieces of information -- one having to do with nomenclature, and
the other with concept circumscriptions.

> I think what I am saying is that it is very useful to pass names around
> as objects and people will do it whether we want them to or not.

But if we can give them an "easy" way to pass such name objects around in
the form of Nominal Concepts, we get the best of both worlds.

The main stumbling block is the limitations of imposing appropriate business
rule enforcement within an XML schema (or, conversely, the cost in terms of
simplicty and comprehension by the first generation of TCS-implementers in
structuring it as Bob has done that does implement some enforcement).

> * Having names embedded does make passing name data very awkward or
> involves creating notions of 'special' concepts of various kinds to
> cover up the fact that we are really just trying to pass nomenclatural
> data.

Fair enough -- but I think the idea of a Nominal Concept has its own
legitimacy from a concept-centric perspective, to be able to represent the
huge body of legacy name-only data within a concept framework.  The only
real problem with my approach (that I can see) is the reliance on data
provider compliance with certain business rules that are difficult to
implement within an XML schema.

> Would be grateful for people's thoughts. Keep it shorter than I have
> been though :)

NOW you are asking too much of me!!!! :-)

> A simple 'Agree' or 'Disagree' from as many people as possible would be
> really useful. You can do it off list if you like!

Sort of agree, sort of disagree.... :-/

Rich





More information about the Tcs-lc mailing list