Re: [topicmaps-comment] mergeMap Pointing to More Than One topicMapElement

[Rex Brooks <rexb@starbourne.com>]

Gentlebeings,

I follow your list, but because of my involvement with HumanMarkup 
and Web Services, I don't often have much of anything to say wrt your 
work, but this thread raises a couple of issues for both Web Services 
and HumanMarkup, with more concern wrt HumanMarkup. My concern is 
that I have already recommended that HumanMarkup adopt and adapt the 
DAML-OIL ontologies. We have to harmonize our vocabulary with many 
others, but especially with TopicMaps in general and PubSub in 
particular. We haven't voted yet to adopt that set of upper 
ontologies, and I don't know if there are any significant conflicts 
or discrepancies between DAML-OIL and Cyc, which, (correct me if I'm 
wrong) you tend to favor.  However, regardless of that, which we can 
adapt to, allowing through the specification for known ambiguities in 
allowable practices for merging maps could cause us some headaches 
since we expect to recommend TopicMaps as the primary 
lookup/association reference for HumanMarkup-based applications to 
use.

To boil it down to the two concerns, is there a clear reason to 
prefer an upper ontology, and is there a significant vulnerability 
through the mergemap ambiguity for proliferation of non-specific 
associations in a returned map that includes merged maps?

I really just want to know if I need to listen in on your list more 
carefully. Your work is very important to us. I wish I could clone 
myself, but I can't so I have spend my time as wisely as I can to 
keep up with the more important work that bears on the efforts in 
which I actively participate.

Thanks.

Ciao,
Rex

At 11:53 AM +0100 6/21/02, Murray Altheim wrote:
>Lars Marius Garshol wrote:
>
>>[...]
>>| Although allowing several <topicMap> elements as children in a
>>| larger DTD seems quite a weird concept to me ... but weird DTDs do
>>| exist :))
>>
>>I think there might be legitimate reasons for doing such things, and
>>it would in any case be poor specification design if we disallowed
>>something we weren't absolutely sure would be an error.
>
>
>I disagree. XTM was designed as an interchange language, not a
>catch-all for all possible "legitimate" topic map expressions.
>Since there is a simple solution for this within the current
>specification, I don't see that opening up the specification
>merely because there *may* be reasons to express something in
>an alternative (and potentially more problematic) way would be
>a benefit for anyone.
>
>It would be poor specification design to allow anything anyone
>can think of merely because they can think of it. It's the
>nature of specification to provide reasonable constraints, and
>XTM as an interchange format has such reasonable constraints. I
>don't want to have to write processors to pull XTM content out
>of ambiguously-marked up XML. What a mess!
>
>Murray
>
>.......................................................................
>Murray Altheim                  <http://kmi.open.ac.uk/people/murray/>
>Knowledge Media Institute
>The Open University, Milton Keynes, Bucks, MK7 6AA, UK
>
>      In the evening
>      The rice leaves in the garden
>      Rustle in the autumn wind
>      That blows through my reed hut.  -- Minamoto no Tsunenobu
>
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>


--