integrating all TMAs: was Re: [sc34wg3] to advance Topic Maps

[Graham Moore]

Hi Patrick,=20

Firstly, thank you for engaging in this discussion I think something
really constructive can come out of it.

1. This was the objective in the TMM that caused me concern and I called
'unambiguously integrate different topic maps'.

parid0770] When two or more topic maps are merged automatically, the
Topic Maps Model:=20

[parid0771] enables the merging process to be consistent across Topic
Map Applications and their implementations, and=20

This for me implies that somehow I can define different TMAs with
different SIDPs and that once everything is merged the TMM view will be
automatically consistent. What I can't understand is how this can work.
Are all SIDPs considered equal at the TMM level?

2. I agree that the TMM appears to have enough machinery to disambiguate
OPs and SIDPs across TMAs this is not a problem.

3. Arbitrary complex structures as SIDPs. The TMM states=20

[parid6045] The definitions of property classes specify the types of the
values of their instances. The value type of a property may be simple
(without substructure) or complex (having substructure nested within
it). The values may be or include lists and lists treated as sets.=20

Which says properties may be complex - for example a BaseName in SAM
would be a TMA property with structure. Properties can be identified as
SIDPs. Therefore identity can be complex in nature.

There are several problems I see with this:

3.1. The general issue related to (1) above regarding which SIDPs are
equal. i.e. in the SAM resource references are equal to resource
references, subjinds to subjinds in the TMM are any SIDPs equal.

3.2 The TMM is not expressive enough to say which parts of the complex
structure constitute the identity. i.e the Name value plus the scope but
not the variants for example.

3.3. The TMM is not expressive enough to say in a TMA that some
properties are conditionally SIDPs. Take the TNC, where its optional if
the name is an SIDP.=20

Now, it may be that those aren't requirements, but I've thought about a
RM->SAM mapping and these were some issues that strung to mind.

4. The last point again relates to the first. i.e. how does TMM handle
equivalence or relation of TMAs. If I understand correctly the intention
is that I can have 2 TMAs with different SIDPs properties. They are of
course internally consistent wrt merging - in the way the SAM is. But
then a third TMA definition could define equivalence of SIDPs. If this
is the case then I think it could work - but it is not clear how do
defined/annotate a TMA using the TMM to say that this SIDPs property is
in fact either this one in TMA1 and this one in TMA2.=20

If this can be clarified then I think there is real value in this - I
just don't see how the engineering the mechanics of what is there really
works to achieve that. That's why I asked.

5. Do you have any comment about the API-like issues I raised?=20

6. I've just read steve's post and I'm also feeling a lot happier with
things. I think I understand the objectives of the RM but as from my
questions above I'm not sure if the RM is engineered yet to support
them.

Regards,

gra


-----Original Message-----
From: Patrick Durusau [mailto:pdurusau@emory.edu]=20
Sent: 14 April 2003 19:40
To: sc34wg3@isotopicmaps.org

Graham,

A reply to one of your "technical points." More to follow later this=20
week. I have changed the subject line so as to divide up the various=20
points you make into separate threads.

Note that some of my analysis of your remarks may be off base since you=20
did not cite the relevant portions of the RM that lead you to the=20
conclusions you offer below. There is a commenting mechanism that has=20
been in place for month that may assist in focusing your comments on=20
particular aspects of the TMM. (see:=20
http://www.isotopicmaps.org/tmmm/TMMM-latest.html)

Graham Moore wrote:

<snip>

>
> Let me explain some of the biggest concerns I have about the new RM=20
> and how they exemplify my comments above. Bernard made a point that I=20
> heartily agree with. He noted, as have I, that the new RM makes a=20
> claim to be able to unambigously integrate all TMAs. This is a bogus=20
> notion.

Not sure what you mean by "unambigously integrate all TMAs." There are=20
no statements that I can find in the TMM that refer to integrating TMAs.

Perhaps you could point me to the portion of the TMM that lead you to=20
this conclusion? If there is language that is mis-leading on this point=20
I would like to know where it can be found.

The TMM requires TMAs to define what properties are used for=20
distinguishing subjects (SIDP) or not (OP). [parid0786] Ah, is it=20
parid0861 that is causing the difficulty?

Parid0861 reads:

***parid0861**
TM Application Definitions can include other TM Applications in their=20
entirety, by reference to their definitions. All of the definitions and=20
constraints of such "included" TM Applications become, without=20
exception, part of the "including" TM Application. The names of included

properties, assertion and role types are not affected by inclusion by=20
another TM Application, and they retain, as their first field, the name=20
of the included TM Application. If the included TM Application itself=20
includes other TM Applications, recursively, they, too, are included.
**/parid0861**

Depending upon what you mean by "integrate all TMAs" is this the trouble

spot?

Looks like a mechanism that distinguishes all the properties defined by=20
one TMA from those of another. Note that the "including" TMA would have=20
to define the SIDPs for topics and could make use of the properties from

the other TMAs, which are distinguished in terms of their origin.

Nothing about automatically integrating TMAs nor anything particularly=20
remarkable about distinguishing properties by their origin.


> The RM says that you can have any arbitrary complex data structure and

> denote it as an 'identity' structure. While the RM would claim this is

> something that enables integration of knowledge in fact it, as Bernard

> alludes to, completely devalues the concept of identity.

Sorry, I lost you here in terms of what part of the TMM makes this=20
claim. Can you point me to the section you are reading this way?

> Knowledge integration can only be achieved by agreement not by total=20
> openess. If I have two TMAs where they both have a property 'ID' but=20
> in one case the strategy for ID is to use web pages as identity for=20
> people and the other makes a distinction. Then when these are 'merged'

> at the RM level we have complete nonsense - we have RDF's problem of=20
> identity crisis. As I see it the RM holds common knowledge identity=20
> integration as a core principal but fails to achieve that goal. The RM

> notion of identity is so weak that it completely goes against the very

> idea of TopicMaps.
>
>
Not guilty.

Reading parid0861 leaves one with the definite impression (the correct=20
one BTW) that to do the 'merger' you refer to in your post would require

a third TMA that governs the topic map instances that are governed by=20
your other two TMAs. The property 'ID' for each of your topic map=20
instances would be denoted as originating from their respective TMAs and

the including TMA would have to declare how it was going to handle=20
identity. Thus, the TMM requires the very agreement that you posit,=20
correctly, as the basis for knowledge integration. (Although I note that

the TMM does not even use the terms "knowlege integration" either as a=20
phrase or as separate words. It has the less ambitious goal of setting=20
forth the model of topic maps and rules for TM Applications.)

Patrick

--=20
Patrick Durusau
Director of Research and Development
Society of Biblical Literature
pdurusau@emory.edu
Co-Editor, ISO Reference Model for Topic Maps


_______________________________________________
sc34wg3 mailing list
sc34wg3@isotopicmaps.org
http://www.isotopicmaps.org/mailman/listinfo/sc34wg3

_____________________________________________________________________
This message has been checked for all known viruses by Star Internet
delivered through the MessageLabs Virus Scanning Service. For further
information visit http://www.star.net.uk/stats.asp or alternatively call
Star Internet for details on the Virus Scanning Service.

_____________________________________________________________________
This=20message=20has=20been=20checked=20for=20all=20known=20viruses=20by=20=
the=20MessageLabs=20Virus=20Scanning=20Service.