[topicmapmail] multidirectional property of associationrole

[Lars Marius Garshol]

* Lars Marius Garshol
|
| Oh, so you don't follow the standard at all?
| In that case I guess it doesn't matter what you do.

* Bernard Vatant
| 
| Let me be clear about that once again, and hopefully once for all. I
| have heard recently, e.g. in Orlando XML 2001, people saying things
| like "Ontopia and empolis are clearly developing topic maps
| technology, but we don't really figure about Mondeca. What you do is
| quite "mysterious". It seems that even for Lars Marius, there is
| still some "mystery" hanging around there :))

Of course there is. I have never seen your software, beyond a single
low-resolution screenshot, so how could there fail to be "mystery"?
 
| Things are not that mysterious. Ontopia and empolis products use XTM
| syntax in their core technology. 

No! Absolutely not! This is an old superstition, but there is nothing
whatever to it. 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. 

I don't know about empolis, but Ontopia supports three different input
syntaxes (XTM, HyTM, and LTM) and three different output syntaxes
(XTM, HyTM, and canonical XTM). In addition you can also import RDF
straight into the model, provided you have a mapping file.

Graham and I are now working on producing an official data model for
topic maps, to become part of ISO 13250. Once that is complete it will
be obvious to all and sundry what is necessary to conform to the topic
map standard, and what is not. (Anyone who wants to participate in
this work: let me know, and I'll do what I can to help you.)

| That means that their engines really "process" and sort of "stand
| upon" XTM, if this is the correct wording for it.

Yes, that is a far better way to put it. The other is wrong, and worse
than wrong, since it is misleading on crucial points.
 
| 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.

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

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

| 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. 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. (Search for my name on xtm-wg and TOPICMAPMAIL and you'll
find more explanations of this than any sane person would care to
read in one go.)

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?

If you can honestly say that TMQL/TMCL/TMSL-T will cause no problems
for you you should be fine. If you cannot you have a major problem.

| For the sake of language interoperability, we call "topics" the
| hypergraph nodes, and "associations" the hypergraph hyperedges.
| Nodes and hyperedges can be attached various attributes, some of
| them can be interpreted as topic names, topic occurrences, or
| scopes.  We allow other interesting attributes like e.g. possible
| *time validation* of nodes and edges, which have no satisfying
| simple equivalent in the TM model so far, that's why we are proud
| enough to consider that our internal structure is more flexible and
| generic than topic maps :))

So long as it is a true superset all should be well. If there happen
to be cases where there is a mismatch we have a problem. For example,
are you sure that you implement merging according to specification?
What about variant names?
 
| Coming back to "association templates". To build and expand the
| graph needs using predefined patterns. There is a primitive pattern,
| where all recursivity ends, which is the "primitive association
| template", with two "primitive roles", namely "association type" and
| "role type".
|
| Thus when we want to create an "employment" association, we need
| first to create an association template, built on the "primitive
| association template", with "employer" and "employee" playing the
| role of "role type" and "employment" playing the role of
| "association type".  For consistency, you have to declare also
| "employer" and "employee" as instances of role type, and employment
| as instance of association type. This will not generally appear in
| an exported topic map, but it would look like the following, if
| necessary. There again, this TM structure is most of the time
| "virtual" in Mondeca engine.

Hmmmmmm. Is it possible to import *any* XTM file into this structure,
without any prior setup?

Eventually there will be a conformance test suite, with a set of XTM
input files and a corresponding set of Canonical XTM output files.
That will allow anyone to test for themselves whether or not vendors
conform to the standards.
 
| 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? Have you been able to load the Italian
Opera Topic Map into your software? Have you tried?

| But they will not necessarily show in an XTM export. 

That's not necessarily a problem. Empolis does the same thing,
although I never understood why. As far as I can tell this template
stuff could perfectly well be exported in XTM syntax by using PSIs.

| And BTW what is the way in XTM to check for that kind of
| consistency? 

There is no way to do it. And, more importantly, there is no
requirement that there be any kind of consistency. This was considered
a feature at the time the specification was written, and I still think
it is one.

The TMCL work is about creating a way to do this kind of check for
those who wish to, but to provide a much more complete solution than
association templates can ever hope to do.

| The association template issue is still open in topic maps AFAIK ,
| and I never understood why it was such of an issue, since the above
| example shows a very natural way to deal with it.

It's an issue because some people think it's a poorly designed
half-way measure that gives us just a tiny fraction of what is really
needed. That's why there is a TMCL work item in ISO. TMCL will
eventually do this, and not just for associations.
 
| 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.

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.

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.

Of course, when you just see the association type outside any
particular context it's best if the name does not imply direction, but
that's a fairly rare case.

| Hope that helps - BTW Lars Marius, does that still mean for you that
| we "don't follow the standard at all"?

I can't tell. You haven't provided enough information, but it doesn't
sound very promising. Generally people don't succeed in following a
standard as complex as XTM 1.0 unless they work very hard at it, and
to me it doesn't sound as if you've done that.

We were very careful when writing our XTM reader in order to make sure
that we followed the specification. Geir Ove wrote the software, and I
wrote a sadistic set of automated test cases to test for every twisted
sort of XTM file I could imagine, to make sure that we handled them
all correctly. Now, whenever we find a problem, we add a new test case
to make sure that the problem never comes back.

We have also had large numbers of people test the Omnigator, and every
problem they have reported has been fixed. I have loaded every single
topic map I could lay my hands on into our software to make sure that
it works correctly, and made sure every problem I could discover that
way was fixed.

Even so we have no guarantee that everything is correct, which is part
of why we would like to see an XTM Conformance Testing project within
OASIS. (The time isn't ripe yet, but we are trying to make it so,
through the ISO model work.)

-- 
Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
ISO SC34/WG3, OASIS GeoLang TC        <URL: http://www.garshol.priv.no >