[tcs-lc] Names as Objects

[Richard Pyle]

> Given that you don't want to pull out the names as top level
> objects - how can you separate out the relationships.

By restricting the kinds of relationships that apply to TaxonConcepts of
type="Nominal", from the kinds of relationships that apply to TaxonConcepts
of other types.  The "ID" for the name object, in my mind, would be
inherited as the ID for the correspoding Nominal Concept.  This way, anyone
whp tries to link directly to a "Name" will actually be linking directly to
a Nominal Concept (with all the fuzzy concept circumscription limits thereby
implied).

> We don't
> actually model the different types of concepts in the schema as
> there is so much optionality built in that you can represent any
> kind of concept with the schema. Therefore there is one
> TaxonConcept modelled for which there is a list of possible
> relationships - still to be tuned but currently includes
> nomenclatural and concept relationships.

Yes, but Nominal Concepts already have to be treated as a sort of "special
case" in how the limits of the implied circumscription are to be
interpreted.  If there is no such "special case" treatment, then I have
other ideas about representing it.  It may be, as per discussions with Bob
and Sally, that no such "business rules" can be imposed via the schema, and
it's up to the software interface to restrict the kinds of relationships
that are allowed for Nominal vs. non-nominal relationships. Perhaps it
relies on the data provider to format the instance document within those
prescribed limits -- and maybe that's a bad thing.  But I'm trying to find
the solution that solves as many problems simultaneously as possible.

> >However, I think there is a solution that is glaringly obvious
> >to me, which
> >is to equate "Nominal" concepts of TCS with Name objects.
> >
> would need to redefine Nominal concepts and think about how they
> would relate to Original and revised and how other biologists
> would use them.

Agreed -- that is probably what we would need to discuss most (if others
feel that this approach could be seen as palatable & workable to both
name-centric and concept-centric ideologies).  I have some ideas, and will
articluate tonight.

> >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?
> >
> Why can't they refer to a nominal concept as defined by TCS which
> is a scientific name AccordingTO NULL?

The Nominal Concept would still have AccordingTo as NULL, but if there is a
desire to capture nomenclatural details, it would be more modular to have
such details packaged with the Nominal Concept instance, rather than having
to pass the corresponding Original Concept as weall as any other concepts
that contained nomenclaturally significant information.

> >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).
>
> I guess I think it can hurt -

I think that position is based on your assumption that my idea includes an
"AccordingTo" value for Nominal Concepts (which it does not).  Does the
explanation in my previous email change your perspective at all?

> If we have names as objects and
> therefore have GUIDs for them,

...inherited from their Nominal Concept instances, which have NULL
AccordingTo

> we can't create TaxonConcepts
> until we have sorted out the names as we would need the names to
> create a Concept so we would be discouraging anyone from marking
> up their data with concepts - even it they are of unknown meaning.

Not necessarily -- Name (Nominal concept) instances could be created with
whatever data is available.  If insufficient information is available, then
the non-Nominal Concept instance might only have a "NameVerbatim" value
(with whatever info it did have), and no pointer to a corresponding Nominal
Concept (from which the name details would be derrived, if they were known).

It only becomes a real problem when we start assigning GUIDs -- which is a
larger topic of discussion.

> If we let people mark up their data with names

...only via Nominal Concept instances (which, in my view, would contain the
nomenclatural data).

>-  we need to have
> Name GUIDs and then Concept GUIDs and these will be different
> things that software and users will need to know about and will
> need to select and interpret accordingly.

Not if the "Name-GUID" is *defined* as the corresponding "Nominal
Concept-GUID" (I imagine a 1:1 correspondence between a "name object" and a
Nominal Concept.

> If we treat names as
> concepts we have one GUID space.

...as we would under my proposal.

> As we create names we are
> creating concepts for people to use and things could progress
> more swiftly.

Yes, as we create names, we would be (by definition) creating them in the
context of Nominal concepts.

Rich