[topicmapmail] multidirectional property of associationrole

[Bernard Vatant]

Lars Marius

Quick answer to some points:

> I have never seen your software, beyond a single
> low-resolution screenshot, so how could there fail to be "mystery"?

I'm well aware of that. We don't have any "light download" version of the software, since
it requires Oracle + specific installation.
That was a deliberate original choice, on which Jean could expand more - I plead not
guilty on that :))

> Both Ontopia and empolis use a core object model,
> based on the implicit data model of XTM.
> These models differ slightly, but are in essence the same.

That's where we differ, and I am not sure you caught it. The "implicit data model of XTM"
is not the core object model of Mondeca, and Mondeca never pretented it was.

BV
> | 1. The core technology architecture (Oracle data base + graph
> | manager architecture) has been developed more than two years ago, at
> | a time where Mondeca was not even aware of topic maps concepts, let
> | alone XTM which was not developed at the time.

LMG
> That's no excuse. We implemented the implicit model of 13250:2000, but
> changed it to follow XTM when XTM was released. Now we support both. I
> can't tell for certain, but I assume empolis must have done the same.

I'm not seeking for excuses. Just giving historical explanations. Mondeca has supported
Topic Maps specification and XTM development and still does inside OASIS TCs, but never
pretended that its core model was fully conformant to anything apart its own original
conception of what a "semantic graph" is - which happened to fit nicely with, say about
90%,
the topic map "implicit model" (whatever that means)

BV
> | 2. Mondeca has always considered afterwards XTM like *one among
> | many* import-export formats, but never the only one, nor even a
> | necessary one in many customers applications.

LMG
> You are no different from us there. I've been saying this exact same
> thing over and over again on these mailing lists.

Let me be more precise, so that you really catch my point. Mondeca has always considered
*topic maps* like one form of structures they could/would manage. That's not only a
question of *format*, but really a question of *model*. We know pretty well we have
internal features that do not conform to the TM model. For example we can "filter" (scope)
and name every single object, be they nodes or edges, and that goes down to allowing
scoping
types and naming associations, and some more of the same "heretic" kind. If we want to
export
XTM conformant files, we have to be careful not to use some features of the software.
That's all. To go to the core of the debate, our graph searchers have always considered
the topic
map model as unnecessarily convoluted and constrained in many aspects. And basically I
sort of agree with
them :))

> | We deal with various situations where the main user concern is not
> | format interoperability, but internal needs for managing legacy or
> | publication. Input and output of the data base can therefore be in
> | all sorts of customized ad hoc XML formats, as long as they can be
> | expressed in terms of the generic mathematical structure the core
> | technology deals with, namely a labeled hypergraph. Could be RDF,
> | whatever ...

> This is not an argument for not following the XTM data model.

There again I'm not seeking to argument, just to explain. We had a strong core model from
the beginning, that we still consider to be more generic than the XTM data model, and even
the
topic maps implicit model. It is a mathematical model standing on graph theory, which is
IMO a quite reliable support. So why would we change, and add constraints to conform to a
model that would restreint our capacity to deal with others?

> It is *crucial* to understand that topic maps are not about syntax, they are
> a *model* and if you want to implement topic maps you must follow the
> model, regardless of whatever syntaxes you happen to support or not
> support.

*You* want to *implement* topic maps. We just want to be able to import/export them.

> What are you going to do when TMQL and TMCL appear, based on the
> Standard Application Model, and assuming that all implementations
> follow it? What will you do if Holger's idea of TMSL-T becomes
> reality, since that, too, will have to build on the SAM?

We're not yet there.

> | The engine will not allow any association to be created without
> | following some predefined template, and will not allow an
> | association declared "instance of employment" to use other roles
> | that "employer" or "employee". Those constraints are inherent to the
> | graph consistency.
>
> Then it seems that you don't have a true superset of the XTM model,
> since there is no such concept in XTM. Can your software even perform
> a straightforward XTM import?

Nope without some preparation. It needs the templates to be defined first, as said before.

> Have you been able to load the Italian
> Opera Topic Map into your software? Have you tried?

Nope. For the above reason I guess. Or out of sheer unwillingness of the developers to do
so ;-)

BV
> | Concerning names: Having some consistency in naming role types and
> | association types is just a conveniency for data base managers and
> | authoring tool users. And of course for exchanging XTM, and
> | certainly published subjects are to set best practices there
> | ... Using substantive nouns seems generally to be the most fit for
> | labeling non-directed edges. No more no less.

LMG
> I disagree very strongly. If you do that you'll end up with lots of
> topic maps that are very hard to understand for users. It's far better
> if the association has a natural name when you look at it in one
> direction, and another natural name when you see it the other way,
> than for it to have the same awkward name in both directions.

Hmm ... I think we have collapsed two problems

The first one is labeling in some standard way roles and associations for internal TM
management and exchange.
It is for that one that I think we should stick to substantive non-directed labels.
The second one is the rendition for end users, which, I agree with you, should be the most
natural possible.

> To take the Puccini/Lucca example, it's better for the user to see
> "Puccini, born in: Lucca" and "Lucca, birthplace of: Puccini" than
> some noun-based phrase that tries to force natural language to do
> something that is not natural for it to do.

What is natural and non-natural anyway? When you read a table with column titles "person"
and "birthplace", that is not maybe *natural* language but it is crystal clear for even
the most basic information user, from age 7 and up ...

Bernard