[tcs-lc] Names as Objects

[Richard Pyle]

Sally wrote:

> As someone who has actually implemented a very old version of
> the TCS as an output from IPNI, can I just say that it's quite hard to
> produce separate lists of publications, vouchers etc. and reference
> them from within the TaxonConcepts. So adding in a third set of
> references to names would be an additional burden.
> The schema might look more modular as a design but it's a bugger
> to implement so on practical grounds I'd reject this suggestion...

Just to be absolutely clear (one more time) -- I am not advocating that we
actually pull "name objects" out from TaxonConcepts and establish them as a
root element to themselves (although James may support this approach).  I'm
just asking the hypothetical question, "If this was done, how would it break
or otherwise adversely affect the main function of TCS?"  The point was to
see what the effects would be of unambiguously treating name objects as
distinct from concept objects. Again, I am *NOT* proposing an actual schema
change of this sort.  I had earlier couched similar sentiments with "yet" --
but I have removed such qualifiers now, because I have pretty-much decided
that I would *never* actually propose or advocate such a change myself.  Not
so much for the reasons Jessie has been arguing, nor even because of your
concerns, Sally. But because I now believe that the "Nominal" concept idea
can be used to resolve a lot of the conclift between LC and TCS.

Methinks my "thought experiment" has only helped me understand the issues
better (which I suppose is a good thing, but perhaps not worth the huge
volume of email).  So my focus will now shift back to where it probably
should have been last week (i.e, on Nominal Concepts).

Gregor wrote:

> PS: biology in the form of nomenclature has a large number of
> rules that a
> computer scientists would call definitions of "canonical form" to
> abstract from
> the variation of name-strings-with-author to a name-identity. The
> LC wiki has
> worked out a number of these rules, and there may be more. I
> therefore believe
> that an ID should be given to these nomenclatural objects. Each
> such object
> could have multiple name strings, some of which are unique, some
> shared with
> other objects (homonyms). Circumscriptions concepts then could
> refer to these.
>
> I believe that this is what Rich put up for discussion, which I
> fully endorse.--

Yes!  That captures the essence of (one of) the points I've been trying to
make -- that relationships among Code-regulated names (indpendent of concept
circumscriptions) are robust enough, and important enough, and different
enough from relationships among concept circumscriptions, that it is
preferable to disentangle the representation of those relationships within
the standard schema.

Gregor also wrote:

> I fully agree with Rich and James conjecture to define name
> objects at the root
> level and make them referrable by ID.

See above -- we don't actually agree on this point, because I never actually
believed that names should be represented as root elements in the schema.

However, I think there is a solution that is glaringly obvious to me, which
is to equate "Nominal" concepts of TCS with Name objects.

> To me most importantly, this solves my problem with SDD, that
> people may want
> to use SDD (and closely related, online monograph standards like TaXMLit,
> TaxonX) to CREATE taxon circumscription concepts, rather than
> referring to them. They need, however, refer to a taxon name (and the
nomenclatural
> information about publication and status) choosen for the new concept.

Why can't they achieve this by creating a new concept instance, and from
within that instance refer back to a Nominal concept instance to represent
the name data?

> I fully see that all such activities could possibly become
> embedded in TCS, but
> I think this is not the correct level of modularity. I believe
> even if you
> think you should not neven link legacy data for which only the
> name object can
> be identified, but the circumscription concept remains unknown to a name,
> having the name as an object does not hurt. It lets the
> scientific "market
> forces" sort out which is the better solution.

Again, I think the idea of a "Nominal" concept instance serves this need
extremely well (or at least it can -- depending on how it is ultimately
defined).

> Now UBIF is far from resolved, it is a discussion platform that
> needs input.
> And it may be aiming to high, trying to solve too much. My
> suggestion would be,
> however, to distinguish between a TCS-core that truly deals with taxon
> concepts, and a shell that ties LC, TCS-core, Publications,
> specimens together.

That approach has its appeal with me as well -- but I don't think that will
be the best long-run (or perhaps even short-term) solution.  I do believe
there is a way to represent the fact that names exist in response to
concepts (as Paul has tried to emphasize), but at the same time, disentangle
information that represents properties of name objects from information that
represents properties of concept circumscriptions.

Aloha,
Rich