[sc34wg3] TR: comment - RDFTM: Survey of Interoperability Proposals

Wed, 9 Mar 2005 23:23:14 +0100

This is a multi-part message in MIME format.

------=_NextPart_000_0023_01C524FE.F7A13EC0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Folks

Please find below an exchange with Peter F.Patel-Schneider, which maybe calls for some
answer(s) from TM community.

Bernard

-----Message d'origine-----
De : Peter F. Patel-Schneider [mailto:pfps@research.bell-labs.com]
Envoye : mercredi 9 mars 2005 15:53
A : bernard.vatant@mondeca.com
Cc : semantic-web@w3.org
Objet : Re: comment - RDFTM: Survey of Interoperability Proposals

[This response is about Topic Maps only.  It is thus somewhat irrelevant to
the SWBP WG.  I have thus moved it to the general W3C semantic web mailing
list.]

From: "Bernard Vatant" <bernard.vatant@mondeca.com>
Subject: RE: comment - RDFTM: Survey of Interoperability Proposals
Date: Wed, 9 Mar 2005 03:07:35 +0100

> 
> Peter
> 
> Even if I am not responsible for a single line in the survey, please let me answer to
some
> of your remarks.
> 
> > First, however, a disclaimer:  I am a long-time skeptic of the entire Topic
> > Maps paradigm.  I have tried several times to determine whether there is
> > something interesting in Topic Maps and each time I have been unsuccessful.
> > My skepticism colors many of these comments.
> 
> I remember some exchange we had a while ago and I see your viewpoint is steady on that
...
> Could you be a little more explicit on what you mean here by "something interesting",
> which you define in a very negative way by the fact that you did not find it. I've hard
> time understanding negative definitions, sorry :)) What is it exactly you were looking
> for, and that you did not find? Is it that you did no find anything useful at all (for
> you), or anything usable, or anything that cannot be expressed otherwise, and better? Do
> you think that what Topic Maps try to achieve has no interest, or is it the way they
take
> to do it? Or what? If I say : "I have tried several times to determine whether there is
> something interesting in football and each time I have been unsuccessful" that only
means
> my incapacity to find interest in football,  but it does not change the fact that a few
> people find it interesting, which I fail to understand, but which is a reality. So maybe
> if I was looking at what people are finding in football rather than to football itself,
I
> would understand the interest of football :))

Well, I have never found a formal semantic definition of Topic Maps, even
looking at the ISO documents (which are, by the way, extraordinarily
difficult to read).  I've found some stuff on syntax and some stuff on
operations, but nothing definitional that I was able to use to generate a
semantic view of Topic Maps, either model-theoretically or
proof-theoretically.  Without this Topic Maps remains uninteresting to me,
stuck in the same situation that Semantic Networks were in the very early
1970s.

The new stuff that you point to doesn't improve this situation appreciably.
Consider, for example the "Guide to the topic map standardization"
(http://www.y12.doe.gov/sgml/sc34/document/0323.htm).  It appears that the
attempt to provide a common meaning for Topic Maps is simply an attempt to
provide a common data model, roughly equivalent to trying to get Topic Maps
to the situation that RDF was in 2000.  I don't see anything going further
than this (except, perhaps, a comment about the Tau Model in Topic Maps -
Part 5: Reference Model
http://www.isotopicmaps.org/TMRM/TMRM-5.0/TMRM-5.0.pdf).

I just decided to dig further, and go well outside the ISO definition of
Topic Maps, As there is no pointer to the Tau Model in the above document,
I looked it up on the web, and found The Tau Model - Formalizing Topic Maps
(http://astma.it.bond.edu.au/junk/tau-model.pdf).  From this I also found A
Mathematical Formalism for the Topic Maps Reference Model
(http://www.isotopicmaps.org/tmrm/rm20031014.pdf).  Finally, something
potentially interesting!?  Well, somewhat interesting at least, but not
particularly - these are only starts at what it needed to turn Topic Maps
into a logical formalism.

(By the way, the comments in Section 2 of the Tau Model document mirror
many of my concerns with Topic Maps.)

[...]

> > Topic Maps also are undergoing change, from the ISO definition (ISO/IEC
> > 13250:2000 Topic Maps: Information Technology -- Document Description and
> > Markup Languages, Michel Biezunski, Martin Bryan, Steven R. Newcomb, ed., 3
> > Dec 1999.  http://www.y12.doe.gov/sgml/sc34/document/0129.pdf) to some
> > recent draft proposals (Garshol, Lars Marius; Moore, Graham: ISO/IEC 13250:
> > Topic Maps - Data Model (Final Committee Draft, 2005)
> > http://www.isotopicmaps.org/sam/sam-model/ and Durusau, Patrick; Newcomb,
> > Steven R.: ISO/IEC 13250: Topic Maps - Reference Model (Working Draft,
> > 2004) http://www.isotopicmaps.org/tmmm/TMMM-4.6/TMMM-4.6.html).  Which
> > version of Topic Maps is under consideration?  Does it matter?
> 
> Yes it matters a lot. Everyone having more or less followed the Topic Maps story over
the
> past years is aware of the neverending and passionate debate on what Topic Maps are,
could
> or should be, between tenants of the Topic Maps as data model (SAM) and tenants of a
more
> generic model(was TMMM, now TMRM). Actually the latter has considerably been changed
since
> the quoted reference, current version is
> http://www.isotopicmaps.org/TMRM/TMRM-5.0/TMRM-5.0.pdf.
> 
> It's also true that none of the above makes for a formal semantic model. But please
> consider that those who invented the paradigm, brought it to the status of an ISO
> standard, and to the point of public consideration it is now, are a handful of dedicated
> people who never had the support of neither major industries, nor academic research
> credits. Several times I have asked some people as knowledgeable as you are, Peter, to
> consider helping the TM community to try and deliver some formal model, or to come to
> figure why there is no formal model possible, whatever. But I must admit that the
answers
> I had were not very helpful, more like "go and learn FOL, it's easy, all is right there
in
> my book, page x to y, come back when you have learnt and made your homework". Not very
> helpful. In Mondeca we proposed at a point a mathematical model based on hypergraphs,
> which we had used to built our software meta-model and architecture. It was neither well
> received by TM folks (because it was maths, hence not readable) nor by RDF people
(because
> it was graph theory, hence "only syntax, not semantics" - that's what I was said).

Well, this is certainly a problem.  However, to be blunt, perhaps you
should consider the lack of interest by formalists as a condemnation of at
least the Topic Maps literature.  There are many things that I could be
doing with my time - what I end up doing depends on my interests, the
interests of my company, and the interests of outside funding agencies.
What makes you think that a simple request to do some work on the formal
underpinnings for Topic Maps would elevate this to the top of my to-do
list?  

If I was going to provide formal underpinnings for something, I would have
picked something with more impact, like RDF.  (Fortunately I didn't have to
spearhead this effort, Pat Hayes did, and all I had to do was to criticise
his work.)  Why did I spend the time I did on RDF?  Well, simply because it
mattered to the effort to put DAML+OIL in the mainstream of the Semantic
Web.  Why did I care about this?  Well because DAML+OIL had many
Description Logic features and I care about Description Logics.

I have already spent several weeks investigating Topic Maps, and am
reluctant to do more.  So therefore I politely suggest that those who care
about Topic Maps educate themselves on what makes a logic, or at least a
formal model.  There are many books on this and related subjects, but there
are many other ways to educate oneself besides reading the literature.  I,
and many other formalists, give talks on our work, and, if asked nicely,
will often come for a visit to an academic or quasi-academic institution or
meeting.  Some of us will even accept short-term consulting contracts from
industrial places.  Perhaps the Topic Maps community should invite
formalists to give them talks.

[...]

> > [For indications why this might be the case, consider that Topic Map merging as
> > defined in http://www.isotopicmaps.org/sam/sam-model/ is claimed to not
> > remove all redundant information in a topic map.  How then can it be
> > determined whether a mapping is reasonable?  As well, the procedure defined
> > therein does not terminate.]
> 
> It may be that here, TM folks have gone quite a long way on the issue of identification.
> Merging is simply the final cleaning process triggered by identification, which is, as
> Chris Welty pointed out in a recent message, a very important and difficult issue, and I
> remember Pat Hayes also writing quite a while ago that identification issue was "sadly
> overlooked" by various SW specifications. What TMDM acknowledges, if I catch it well, is
> that even when process of merging is achieved, following the identification rules, one
can
> never be sure if some elements which have not been merged could yet still actually
> represent the same subject, but had not been merged because there was no identification
> rule allowing to merge them. That's what "remaining redundant information" means. In
what
> is OWL-RDF different in this respect? The famous example of the robber and the speeder
is
> a too well ending story ... most of the time, the robber and the speeder *are* actually
> the same guy, but there is neither facts nor rules sufficient to prove it, and, as in
the
> real life, "the procedure does not terminate", and the robber keeps speeding (and the
> other way round), and the police does not know.

Well, in this case there is no redundant information, at least in the
formalism - because the robber and speeder might be different - so I don't
see your point.  

The point I was trying to make is that there is no formal underpinning for
merging, at least in that document.  What role then does this procedure
play?  How should a mapping between RDF and Topic Maps treat it?  

> Best regards
> 
> Bernard Vatant

Peter F. Patel-Schneider
Bell Labs Research

------=_NextPart_000_0023_01C524FE.F7A13EC0
Content-Type: application/ms-tnef;
	name="winmail.dat"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="winmail.dat"

eJ8+Ig4WAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEIAAUABAAAAAAAAAAAAAEJAAQAAgAAAAAA
AAABBoADAA4AAADVBwMACQAXABcAAAADABkBAQOQBgDIBAAAJAAAAAsAAgABAAAACwAjAAAAAAAD
ACYAAAAAAAsAKQAAAAAAAwAuAAAAAAADADYAAAAAAB4ATQABAAAAAQAAAAAAAAAeAHAAAQAAADYA
AABjb21tZW50IC0gUkRGVE06IFN1cnZleSBvZiBJbnRlcm9wZXJhYmlsaXR5IFByb3Bvc2FscwAA
AAIBcQABAAAAFgAAAAHFJPY9VyOR8B0JWUuNhC7INePNbKMAAAsAFwwAAAAAAgEdDAEAAAAgAAAA
U01UUDpCRVJOQVJELlZBVEFOVEBNT05ERUNBLkNPTQALAAEOAAAAAEAABg4A+juN9iTFAQIBCg4B
AAAAGAAAAAAAAADkSz/SBjJuSK7gLaZ68tiQwoAAAAMAAYAIIAYAAAAAAMAAAAAAAABGAAAAABCF
AAAAAAAACwAEgAggBgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAAAAADACaACCAGAAAAAADAAAAAAAAA
RgAAAABShQAAjmoBAAsAM4AIIAYAAAAAAMAAAAAAAABGAAAAAA6FAAAAAAAAAwA1gAggBgAAAAAA
wAAAAAAAAEYAAAAAEYUAAAAAAAADADaACCAGAAAAAADAAAAAAAAARgAAAAAYhQAAAAAAAAMAToAI
IAYAAAAAAMAAAAAAAABGAAAAAAGFAAAAAAAAHgB3gAggBgAAAAAAwAAAAAAAAEYAAAAAVIUAAAEA
AAAEAAAAOS4wAB4AeIAIIAYAAAAAAMAAAAAAAABGAAAAADaFAAABAAAAAQAAAAAAAAAeAHmACCAG
AAAAAADAAAAAAAAARgAAAAA3hQAAAQAAAAEAAAAAAAAAHgB6gAggBgAAAAAAwAAAAAAAAEYAAAAA
OIUAAAEAAAABAAAAAAAAAAsAfIAIIAYAAAAAAMAAAAAAAABGAAAAAAaFAAAAAAAAAwCigAggBgAA
AAAAwAAAAAAAAEYAAAAAQoUAAAAAAAICAaeACCAGAAAAAADAAAAAAAAARgAAAABAhQAAAQAAADEA
AAADAQEAAABFAAAACwAAAAAABgBTAGMAYQBuAGUAZAAGU2NhbmVkAAAAAAQAAAAAAAAAAAAACwC0
gAggBgAAAAAAwAAAAAAAAEYAAAAAgoUAAAEAAAALAHKEKQMCAAAAAADAAAAAAAAARgEAAAAOAAAA
UwBjAGEAbgBlAGQAAAAAAAEAAAACAfgPAQAAABAAAADkSz/SBjJuSK7gLaZ68tiQAgH6DwEAAAAQ
AAAA5Es/0gYybkiu4C2mevLYkAIB+w8BAAAAqQAAAAAAAAA4obsQBeUQGqG7CAArKlbCAABQU1RQ
UlguRExMAAAAAAAAAABOSVRB+b+4AQCqADfZbgAAAEM6XERvY3VtZW50cyBhbmQgU2V0dGluZ3Nc
QmVybmFyZFxMb2NhbCBTZXR0aW5nc1xBcHBsaWNhdGlvbiBEYXRhXE1pY3Jvc29mdFxPdXRsb29r
XERvc3NpZXJzIHBlcnNvbm5lbHMgKDEpLnBzdAAAAAADAP4PBQAAAAMADTT9NwAAAgF/AAEAAAA6
AAAAPEdPRUlLT09BTUpPTkVGQ0FOT0tDQUVCR0ZMQUEuYmVybmFyZC52YXRhbnRAbW9uZGVjYS5j
b20+AAAA1c8=

------=_NextPart_000_0023_01C524FE.F7A13EC0--