[topicmapmail] multidirectional property of associationrole

[H. Holger Rath]

Hi,

Lars Marius Garshol wrote:
> ... snip ...
> 
> | 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.

k42 imports and exports XTM and (in next release) RDF.

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

Yep, but we decided to no longer support HyTM syntax.

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

I really look forward to have this conformance test suite. Looks like 
the next OASIS TC.
 
> | 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. 

k42 (empolis) is *not* doing the same thing. We support templates
similar to the templates described by Bernard but k42 exports
*all* template information into XTM. And everything is well 
documented in the docu. And k42 also understands 'regular'
XTM assocs without having any template - when importing regular 
XTM k42 tries to build the templates from the existing assoc 
structures. Similar to the stuff Geir Ove talked about - I think in
Paris at XML Europe 2000.

> As far as I can tell this template
> stuff could perfectly well be exported in XTM syntax by using PSIs.

That's how k42 is working. We use empolis PSIs to express our
proprietary template information.
 
> | 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.

True. And I really look forward to have TMCL in place.
 
> | 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.

I second.

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

Lars Marius, I think Bernard is naming the assoc with nouns in the
modelling process only - as I do as well. The rendition of an
assoc to the 'regular' user of the map (and not the editor/ author)
will use verbs with directions - as Bernard points out somewhere else
in his email when he talks about rendition.
 
> 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 >
> 
> _______________________________________________
> topicmapmail mailing list
> topicmapmail@infoloom.com
> http://www.infoloom.com/mailman/listinfo/topicmapmail

-- 
Dr. H. Holger Rath
- Director Research & Development -

empolis * GmbH
Bertelsmann MOHN Media Group
Technologiepark Pav. 17
97222 Rimpar, Germany

phone :  +49-172-66-90-427
fax   :  +49-9365-8062-250

<mailto:holger.rath@empolis.com>
http://www.empolis.com