[tcs-lc] Name-Name Relationships vs. Concept-Concept relationships

[Gregor Hagedorn]

Jessie wrote:

> Name-Name relationships are explicit for 2 reasons (not necessarily good
> design reasons!)
> 
> 1.	We are trying to separate names from concepts and not to mix the
> two so one of my concessions to moving names to top level objects was
> that we would allow names to be related to concepts in any way other
> than by allowing a concept to point to a name. The easiest way of doing
> this was to be explicit about the relationships allowed between names.
> So if you have relationships other than those listed then you were
> wandering into concept territory and maybe you should be dealing with
> concepts rather than names. I believe from discussion on tcs-lc and from
> discussion with Roger who had private conversations with some folks that
> those listed covered what the nomenclaturists required. If this is not
> the case then we need to know. Roger can confirm  (or deny this) I also
> believe that some of the relationship types you list Rich are subsumed
> by those we offer again Roger can confirm.

> 2.	The second reason is that it looks more like the original
> Linnean core representation that everyone seemed to like...and just for
> good measure - related to point one it's easier to add new instances to
> an enumerated list than to change the schema structure so I thought that
> we would be able to keep the separation between names and concepts more
> easily if we did it like this. Concept relationships in the other hand
> are more numerous abd possible more likely to change although some
> thought has gone into this list by various people in TCS and SEEK and
> based on what is commonly used by others.

As Jessie says, this was already discussed in St. Petersburg, and I made my 
points there. Please excuse any repetition. However, I wonder why I agree with 
99% what Jessie says and still think the use of sequences of element names with 
the same type (i.e. role distinguished by element naming) and collections of 
same type with role distinguished by enumerated attribute value should be 
consistent. I mean *internally* consistent within TCS; I agree no general 
design applies here yet.

Some points:

- Controlling an enumeration is equally strong with controlling the sequence in 
schema.

- Extending a sequence of elements is more difficult in an upgrade than 
extending an enumeration. That applies both to applications based on tcs and to 
the schema itself.

- Fundamentally, the sequence of role-element-names is a collection, not a 
sequence. Order has no meaning here.

- The two cases are fully separated by structure (in different context). Even 
if for nomenclatural relations the enumeration-value method would be used, it 
is impossible to mix the two purposes.

- However, my gut feeling is that Nomenclatural relations are icomplete. If 
they aren't, any change in the codes will make them so. So extension of these 
relations (for valid reasons, not in an attempt to confuse with concepts) 
should be supported.

- Finally, the similarity with LC does not convince me. the flattened out 
design of original LC was designed to allow flat table representation, which is 
a value. However, this is not preserved, at least two relations are collections 
rather than single.

Gregor----------------------------------------------------------
Gregor Hagedorn (G.Hagedorn at bba.de)
Institute for Plant Virology, Microbiology, and Biosafety
Federal Research Center for Agriculture and Forestry (BBA)
Königin-Luise-Str. 19           Tel: +49-30-8304-2220
14195 Berlin, Germany           Fax: +49-30-8304-2203