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

[Kennedy, Jessie]

> 
> For what it's worth, I agree 100% with Gregor's points as outlined
below.
> But I suspect this is well beyond the "minor" catgeory, and thus
probably
> best left for a later discussion (i.e., after Sep. 30).

Agree..but...
> 
> Aloha,
> Rich
> 
> > Some points:
> >
> > - Controlling an enumeration is equally strong with controlling
> > the sequence in
> > schema.
Yes when in use..
> >
> > - 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.


Yes - this was my original point
> >
> > - Fundamentally, the sequence of role-element-names is a
> > collection, not a
> > sequence. Order has no meaning here.
Agree - something you get with XML that you don't always want...but we
don't need to read semantics into it for more than validating purposes.
> >
> > - 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.

Yes but....if we have the generic relationship approach to TaxonNames
and I added a concept type of relationship to the enumeration of
relationships allowed I would be worried that people would start marking
up names where they should be using concepts... and we'd never improve
our data... 
> >
> > - 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.

We have tried to investigate the issue of relationships as I mentioned
before - if some other taxonomists wants to find what's missing that
would be great. How often does the code change at that sort of level?
I'm sure there will be many versions of all standards and
implementations before the code changes this sort of thing - but I could
be wrong...
> >
> > - 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.
> 
If it's not preserved it wouldn't have been able to preserve it in LC
style either - so LC must've been wrong in that respect too - so not
sure the point of that - except that we need to review the relationships
that are indeed multi-valued as opposed to single valued. I think Roger
was going to look at that - were you Roger? It came up in St Pete


Jessie
This message is intended for the addressee(s) only and should not be read, copied or disclosed to anyone else outwith the University without the permission of the sender.
It is your responsibility to ensure that this message and any attachments are scanned for viruses or other defects. Napier University does not accept liability for any loss
or damage which may result from this email or any attachment, or for errors or omissions arising after it was sent. Email is not a secure medium. Email entering the 
University's system is subject to routine monitoring and filtering by the University.