OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

topicmaps-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [xtm-wg] [xtm-wg/xtm-iss/xtm-cms] Regarding associations as topics


Steve Pepper  wrote:
> [Nikita:]
> > Suggestions 2) 3) above yield to jeopardizing integrity which
> > is clear from the following:
> > 2)
> > <topic id="t2" types="some-other-assoc-type">
> > <locator href="a" type="is"/>
> > </topic>
> > <topic id="t1" types="some-assoc-type ">.</topic>
> > <assoc id="a" type="t1">...</assoc>
> >
> > 3)
> > <topic id="t2" types="some-other-assoc-type">.</topic>
> > <topic id="t1" types="some-assoc-type ">.</topic>
> > <assoc topic="t2" type="t1">...</assoc>
> >
> > Integrity is broken in both cases if
> > Topic "t2" is not an instance of "t1"
>
> To me this is not an argument. The same situation exists with
> respect to the merging of topics (whether it is occasioned by
> the identity attribute mechanism or the topic naming constraint):
> The topics being merged may have different types. If so, the
> merged topic becomes an instance of multiple types.

Not exactly.
When merging we can avoid ambiguity with the help of scopes.
In this case we can not. For example:

<topic id="t2" types="polygamy">
<locator href="a" type="is"/>
</topic>
<topic id="t1" types="marriage">.</topic>
<assoc id="a" type="t1">...</assoc>

Suppose with xtm-schemas or templates we
enforced that for associations of type "marriage"
there is only two participants.
While associations of type "polygamy" do not assume that.
Above situation may suit somebody leading a double live ... ;-)))
But generally should be considered a bug.

The fact is that by allowing our syntax to provide
several alternative ways of expressing association type (or anything
else!!!)
we open Pandora Box.

Well-debugged software may be safe, but human intervention or
buggy software will corrupt the data.
Idiot-proof design is always better especially if it is simple.
I believe that "singleton" provides this kind of  confidence.

> I don't see why having an ID on a non-topic topic map object should
> be unclear. IDs have pretty clearly defined semantics.

Nobody can prevent people from using IDs.
But it should not be required by XTM syntax.
(Do I repeat Eliot's words?)
Users should be warned about possible consequences
of using IDs on non-topics.

> The same would apply in example 3) above. Topic "t2", by dint
> of being the topic that reifies an association of type "t1",
> would be a topic of type "t1" (as well as a topic of type
> "some-other-assoc-type").

Rewritng previous example,

<topic id="t2" types="polygamy">.</topic>
<topic id="t1" types="marriage">.</topic>
<assoc topic="t2" type="t1">...</assoc>

I do not think it looks clear :-)))

>Why do we want associations "to be" topics? Well,
>I'm not sure we do...

I am glad we agree on this, Steve.

Thanks,

Nikita.


-------------------------- eGroups Sponsor -------------------------~-~>
Restaurants, Movies, Weather, Traffic & More!
Call 1-800-555-TELL.  For more info visit:
http://click.egroups.com/1/9533/4/_/337252/_/971323453/
---------------------------------------------------------------------_->

To Post a message, send it to:   xtm-wg@eGroups.com

To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC