[tcs-lc] Names as Objects

Richard Pyle deepreef at bishopmuseum.org
Tue Mar 8 21:57:13 PST 2005


> >I would like to support Rich here.
>
> I'm not sure you do - but Rich can confirm. Rich wants a nominal
> concept I think  not a name object which is what you want.

What I *really* want is the ability to easily pass concept-less
nomenclatural data back and forth without a cumbersome process of
disentagling name information from concept information from within a
mixed-purpose schema.  One way to achieve this is to establish names as
top-level objects (a perspective I could be persuaded to adopt, but am not
sure would be optimal).  Another is to re-define the existing TCS "Nominal"
concept in such away that it serves my needs, and also continues to serve
the TCS need that it was created for in the first place.  I am gaining hope
for this approach as I put more and more thought into it, but there is a
long way to go before I am completely convinced that it is a sensible
solution (let alone convincing everyone else that is a sensible solution).

> I do not (and DID NOT) say we should default to the original
> concept but that for any data where it is unclear what the
> meaning behind a name is we should default to the nominal
> concept!

Sorry -- I think I'm the one who introduced the confusion.  When I
originally used the word "default" to, I was thinking in terms of passing
nomenclatural information around -- not for assigning concepts to name-only
datasets.

> EWvery original concept should have a nominal concept
> that allows people where ambiguity exists to default to the name
> explicitly without a meaning.

On this point, I think we are in full agreement.  Where the point of
contention seems to be is, "Where is the name-object information stored?".
If I understand you (Jessie) correctly, TCS is currently designed with the
assumption that the nomenclatural information will potentially be spread out
over a number of Concept instances connected to each other through
name-relevant Relationship links (which are interspersed among
concept-relevant Relationship links).  This has the advantage of embedding
Nomenclatural Acts within the context of the publication instance
(AccordingTo) that the Nomenclatural Act occured in.  Taxonomer follows this
paradigm, so I clearly understand what makes it an attractive solution.

The reason why I think it is non-optimal for an exchange schema, however, is
that the process of extracting nomenclatrual information from instances that
really should represent concept circumscriptions is non-obvious, and
non-modular. The nomenclatural bits are scattered, and not quickly isolated.
Moreover, many nomenclatural properties are *not* bound to a publiction
(AccordingTo) instance -- either by Code, or by practice.

The solution I'm after is the one that packages nomenclatural information in
an easily-accessed, modular form, but also represents the reality that names
follow concepts (rather than the other way around).

By embedding nomenclatural information within Nominal Concepts, I believe
that we can achieve both.  It does require re-thinking what the "Nominal
Concept" really means, and does elevate its role within a TCS dataset -- but
it does NOT attribute any concept circumscription implications to a Nominal
COncept, which means the Nominal COncept retains its original function
within TCS. It is, to me, the logical place to collect non-concept
nomenclatural information.

Rich





More information about the Tcs-lc mailing list