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

[Roger Hyam]

If we were to use the same mechanism in NameObjects for 
NomenclaturalNotes that we use in TaxonConcepts for Relationships (i.e. 
allow for an arbitrary list of name-name relationships with an attribute 
to indicate the type of each relationship) then we would lose all 
control over cardinality within name-name relationships. A name would, 
for instance, be able to have multiple basionyms.

As the design goal is to attempt to restrict name-name relationships to 
those that are in the nomenclatural codes the current design would 
appear to be preferable.

I knew there was a reason for us going with this layout I just couldn't 
recall it when we were in St Petersburg.

I am therefore going agree with Sally and punt this into the long grass 
(version 2 maybe) unless some one has some other compelling reason to 
keep it on.

Roger


Sally Hinchcliffe wrote:

>Rich wrote:
>  
>
>>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).
>>
>>    
>>
>
>>From what we discussed last week I think in the end the discussion 
>turned on what would be easiest to both produce and to parse. At 
>which point a lot of handwaving ensued ... I agree this isn't minor 
>and hopefully after some people have had a go at writing wrappers for 
>both Name Objects and full-blown concepts we will have some more 
>facts to throw at the discussion. Definitely one for version 2.0 :-)
>
>  
>
>>>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.
>>>      
>>>
>>_______________________________________________
>>Tcs-lc mailing list
>>Tcs-lc at ecoinformatics.org
>>http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/tcs-lc
>>    
>>
>
>*** Sally Hinchcliffe
>*** Computer section, Royal Botanic Gardens, Kew
>*** tel: +44 (0)20 8332 5708
>*** S.Hinchcliffe at rbgkew.org.uk
>
>_______________________________________________
>Tcs-lc mailing list
>Tcs-lc at ecoinformatics.org
>http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/tcs-lc
>
>  
>

-- 

==============================================
 Roger Hyam
----------------------------------------------
 Biodiversity Informatics
 Independent Web Development 
----------------------------------------------
 http://www.hyam.net  roger at hyam.net
----------------------------------------------
 2 Janefield Rise, Lauder, TD2 6SP, UK.
 T: +44 (0)1578 722782 M: +44 (0)7890 341847
==============================================


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/tcs-lc/attachments/20050921/35f71a59/attachment.htm