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

[Steve Pepper <pepper@ontopia.net>]

> At 14:27 09/10/00 -0400, Nikita Ogievetsky wrote:
> There have been several proposals on how to link
> association with a topic link.
>
> 1)turn association into a topic
> 2)bring "id"-s on associations into the standard
> 3)add "topic" attribute on associations

I would characterize these three differently, since all three
are about making associations into topics (in some way), and
since having IDs on associations does not express the essence
of the second proposal:

1) allow associations to have a topic or topic name element
   as a sub-sub-element via the nameservice element type
   (proposed by HHR/GMD - Hans Holger Rath and Graham Moore)

2) address an association as an occurrence of a topic (MB -
   Michel Biezunski's solution)

3) add the -topic- attribute to associations to enable direct
   referencing of the reifying topic (proposed by the Ontopia
   team -- Kal Ahmed, Lars Marius Garshol, Geir Ove Grønmo,
   and myself)

To these, Nikita has added a fourth:

4) introduce a public subject ("singleton") that expresses the
   semantics "class of association with only one member"

First of all: Why do we want associations "to be" topics? Well,
I'm not sure we do: As several people have pointed out, one of
the strengths of the TM model is that it clearly distinguishes
between topics and associations.

On the other hand, having "everything" be a topic adds a lot of
expressive power to a topic map. (Note: Contrary to what is often
claimed, it is *not* the case today that "everything in a topic
map is a topic": for example, association *types* are topics, but
individual associations are not.)

What *I* really want to do is make it possible, at the discretion of
the author and/or user, to *regard* anything in a topic map as a
topic. Perhaps this is something different from "making everything
a topic".

One reason why I want to be able to do this, is to allow topic
maps to be browsable at different levels of detail. At one level
it may be enough for me to know about Henry VIII and his six wives
as six "marriage" associations connecting seven topics. But then I
may want more detail on one of those marriages, say the one with
Ann Boleyn. That association then becomes the subject of my attention
and I want it to be a topic, with its own characteristics.

I think the same applies to occurrences. In some scenarios it will
be useful to regard an information resource that is the occurrence
of one or more topics as a topic in its own right, with its own
characteristics.

So for me there is no doubt that a user requirement exists. The
question is, how do we satisfy it?

[Nikita:]
> I have reservations against all three suggestions.
> Firstly, suggestion 1) depletes (as far as I am concerned)
> the main concept of TopicMaps, which is: "anything whatsoever"
> can be a topic. And topic's participation in associations is
> just another piece of information about a topic.

I'm not quite sure what Nikita means here. However, I do agree that
the nameservice proposal is unsatisfactory.

[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.

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").

This is one of the implications of the proposal that needs to
be spelled out, as we indicate in our comments document at

http://www.egroups.com/files/xtm-wg/Interchange/XTM+-+The+Ontopia+Comments%2
Ehtm

[Michel:]
> Now, if you want to say something about an instance of the marriage,
> e.g. the one between John and Jackie Kennedy, you consider that the
> association you are talking about is an occurrence of the topic
> "Marriage of John and Jackie Kennedy", that might have many other
> occurrences elsewhere, a definition, an identity, etc. This is a
> different topic from the one of the class of marriage.

I see two problems with Michel's proposal:

(1) The semantics of an association element being addressed as an
occurrence of a topic are not defined. It *could* be that the topic
is reifying the association, or it could be something else altogether
(e.g. the topic could be "binary associations", and this could be an
"example"). So for this method to work, at the very least we need a
public subject that can be used to indicate the occurrence role
"topic map construct which is reified by this topic".

(2) Even with such a public subject, from a syntactical point of view
the semantics are in a sense being expressed backwards (i.e. from
the topic to the association, rather than vice-versa). This to me is
obfuscatory and guaranteed to cause confusion. Having a -topic-
attribute on the association is far, far clearer.

[Nikita:]
> There is one peculiarity though:
>
> Only a single association in a given scope can reference this topic.
> This can be achieved by adding "singleton" to the super-types of
> "marriageAtoB" If there are two associations pointing to the same
> singleton type in the same scope, they should be merged.
>
> <topic id="marriageAtoB" types="marriage singleton">..</topic>
> <assoc type="marriageAtoB">
> ..
> </assoc>

Nikita's proposal is a little clearer from the syntactical point of
view, but doesn't in my opinion express the semantic that the topic
*reifies* the association. Specifying that an association belongs to
a class that only has one instance is not the same thing at all.

[Nikita:]
> So having simultaneously both ... {topic and type} on association
> (or on any other non-topic xtm element) is a very subtle matter
> and can not be used without rigorous xtm schema constructs (to be
> defined yet).

[Geir Ove Grønmo]
> the implications of non-topic topic map object having both an id,
> a type and a characterizing topic was totally _unclear_.

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

I do agree that the implications of having both a -type- and a -topic-
attribute need to be spelled out very carefully. But I think spelling
them out is doable, without having to wait for XTM Schema. It may not
be doable in time for XTM 1.0, but I would be prepared to take a stab
at it even so.

My conclusion is that although some of the implications may be unclear
until spelled out, the basic semantics are immeasurably clearer with
the -topic- attribute mechanism than with any of the alternatives.

I look forward to hearing what the Conceptual Modeling Subgroup has
to say about the matter in Swindon.

Steve

--
Steve Pepper, Chief Technology Officer, Ontopia AS. (+47 908 27246)
Ontopia AS, Marcus Thranes gt. 6, N-0473 Oslo, Norway
http://www.ontopia.net/  phone://+47 22704500/  fax://+47 22704501/
direct://+47 22704687/  GSM/cellular://+47 90827246/


-------------------------- eGroups Sponsor -------------------------~-~>
Get free updates on your stocks from any phone with Tellme!
Call 1-800-555-TELL.
http://click.egroups.com/1/9535/4/_/337252/_/971275415/
---------------------------------------------------------------------_->

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

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