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

[Jan Algermissen]

Graham Moore wrote:
> 
> Hi Patrick,
> 
> 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:
> 
> [parid0771] enables the merging process to be consistent across Topic
> Map Applications and their implementations, and
> 
> 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. 

I think I don't understand your interpretation. What th RM tries to say is
that topic maps that are goverend by different TMAs can be represented in
the same structure (topics with properties).

> What I can't understand is how this can work.
> Are all SIDPs considered equal at the TMM level?

No. But then, what do you mean?


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

Sure. The SAM would have an SIDP with a value type (name,scope)
> 
> 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.

The SAM would have two SIDPs for this (SubjectAddress and SubjectIndicators)
see my last mail. It might also have a SOurceLocators property but at least
in my application I don't need it anymore and just make the source locators
SubjectIndicators.

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

The TMM refuses to be expressive enough to do this! Merging rules go into the TMA.
> 
> 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.

Well, you'd have two properties, one OP and one SIDP. Depending on the
syntax you process (e.g. TNC falgged on or of) you'd create either
the OP or the SIDP on a topic. 

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

Glad to see that you think of this mapping! Thanks! All input welcome -
I did most of this mapping, but not everything.

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

That's how it works.

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

Suppose you have

TMA1 which defines the property "foo" and TMA2 which defines "bar"

TMA3 can define a merging rule that says:

"Given that one topic exhibits a value X for TMA1::foo and another topic
 exhibits the value Y for TMA2::bar and given that X and Y relate in a certain
way (e.g. are equal) the merge the topics"

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

Did I clarify this? If not, ask again.

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

what was it?, sorry.

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

The RM might not be clear enough so that everyone understands it, but I now
from my own implementing experience that it provides almost 100% of what
is needed technically.

Jan


> Regards,
> 
> gra
> 
> -----Original Message-----
> From: Patrick Durusau [mailto:pdurusau@emory.edu]
> Sent: 14 April 2003 19:40
> To: sc34wg3@isotopicmaps.org
> 
> Graham,
> 
> A reply to one of your "technical points." More to follow later this
> week. I have changed the subject line so as to divide up the various
> points you make into separate threads.
> 
> Note that some of my analysis of your remarks may be off base since you
> did not cite the relevant portions of the RM that lead you to the
> conclusions you offer below. There is a commenting mechanism that has
> been in place for month that may assist in focusing your comments on
> particular aspects of the TMM. (see:
> 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
> > and how they exemplify my comments above. Bernard made a point that I
> > heartily agree with. He noted, as have I, that the new RM makes a
> > claim to be able to unambigously integrate all TMAs. This is a bogus
> > notion.
> 
> Not sure what you mean by "unambigously integrate all TMAs." There are
> 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
> this conclusion? If there is language that is mis-leading on this point
> I would like to know where it can be found.
> 
> The TMM requires TMAs to define what properties are used for
> distinguishing subjects (SIDP) or not (OP). [parid0786] Ah, is it
> parid0861 that is causing the difficulty?
> 
> Parid0861 reads:
> 
> ***parid0861**
> TM Application Definitions can include other TM Applications in their
> entirety, by reference to their definitions. All of the definitions and
> constraints of such "included" TM Applications become, without
> exception, part of the "including" TM Application. The names of included
> 
> properties, assertion and role types are not affected by inclusion by
> another TM Application, and they retain, as their first field, the name
> of the included TM Application. If the included TM Application itself
> 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
> one TMA from those of another. Note that the "including" TMA would have
> 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
> 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
> claim. Can you point me to the section you are reading this way?
> 
> > Knowledge integration can only be achieved by agreement not by total
> > openess. If I have two TMAs where they both have a property 'ID' but
> > in one case the strategy for ID is to use web pages as identity for
> > 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
> > identity crisis. As I see it the RM holds common knowledge identity
> > 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
> 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
> your other two TMAs. The property 'ID' for each of your topic map
> instances would be denoted as originating from their respective TMAs and
> 
> the including TMA would have to declare how it was going to handle
> identity. Thus, the TMM requires the very agreement that you posit,
> correctly, as the basis for knowledge integration. (Although I note that
> 
> the TMM does not even use the terms "knowlege integration" either as a
> phrase or as separate words. It has the less ambitious goal of setting
> forth the model of topic maps and rules for TM Applications.)
> 
> Patrick
> 
> --
> 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 message has been checked for all known viruses by the MessageLabs Virus Scanning Service.
> _______________________________________________
> sc34wg3 mailing list
> sc34wg3@isotopicmaps.org
> http://www.isotopicmaps.org/mailman/listinfo/sc34wg3

-- 
Jan Algermissen                           http://www.topicmapping.com
Consultant & Programmer	                  http://www.gooseworks.org