[topicmapmail] multidirectional property of associationrole

[H. Holger Rath]

Hi,

Lars Marius Garshol wrote:
> ... snip ...
>
> | I would say that the approach of building SPO sentences work for 80%
> | of assocs in the languages of our target markets. And the remaining
> | 20% are still douable - it is not perfect grammar but a 'regular'
> | user understands what you want to express.  So it is worth
> | considering it, isn't it?
> 
> Personally, I don't want to do things that way. 80% is not enough (if
> you can even get that high), and for omnigating (that is, generic
> topic map browsing) laying out associations as text is awkward, since
> it makes it harder for the reader to quickly get an overview of the
> associations from the current topic.

The quick overview issue is certainly a good point for HTML rendered
TMS. But when you render the TM as a graph labeled arcs are very helpful.
 
> | emplis follows a slightly different approach because we want to be
> | able to label every possible role combination. And for this you have
> | to scope the role names. I assume you agree, that this technique
> | makes sense when this is the goal? Or do you have a better idea?
> 
> It's pretty much the only possible technique, but I don't feel that
> the goal makes a whole lot of sense. Why do you consider labelling all
> combinations worthwhile?

Again, graphical rendition is the challenge.

> | I argued against your solution because I looked at it from the point
> | of view of our approach. I hope you apologize.
> 
> You're the one who is apologizing. I just forgive you. :-)  Or, that
> is, I would have forgiven you if there were anything to forgive, but I
> don't think there is.

In German I should say "Ich bitte Dich um Entschuldigung" and you would
answer "Entschuldigt!". Many Germans tend to do it the wrong way saying
"Ich entschuldige mich" -- you have to ask for "Entschuldigung" in German.
That's why I asked you to apologize, because I thought it is the same
way in English. Seemed to be not.

> ... snip ...
>
> | Proposing TMCL was only an idea, because the verbs belong to the
> | template part of an assoc in k42. But you are probably right that it
> | is not well positioned in the TMCL standard. What could be part of
> | TMCL is the property that an assoc could be factorized as part of
> | the cardinality info about roles, which is somehow related to
> | labelling arc because you better know which arcs are really
> | meaningful and which are not.
> 
> I guess that it does make sense for it to be possible to specify some
> rule about how association type name structure should relate to the
> structure of the associations themselves, but it seems like a very
> complex rule for very little gain.
> 
> If it could be done at little cost I would be all for it, but...

The factorization property might also be used for other issues by
the TM engine. I have not thought about it that much, but I remember
that Rafal Ksiezyk listed factorization as a assoc prop together with
transitivity. But I don't remember for which purpose. => Rafal?
 
> * Lars Marius Garshol
> |
> | This is only needed for generic topic map navigation tools, which
> | are only used for demo and debugging purposes anyway.
> 
> * H. Holger Rath
> |
> | When we generalize the problem we need something that allows us to
> | define how a rendition of a certain map looks like. A kind of TMSL
> | (Topic Map Style Language) with Formatting Objects (TMSL-FO) and a
> | proper Transformation language (TMSL-T). But this is really far down
> | the road ... or anybody already working on this?
> 
> We have the TMSL/TMSL-T already, in a sense, and I've posted about the
> need to standardize such a thing several months ago (October, I think).

Who is "we"? Ontopia or the TM community? I would appreciate it if you
could re-start this thread in a separate posting.

> The TMSL-FO thing doesn't seem necessary to me. Surely XSL:FO can do
> that job?

I am eager to read more about your ideas in that new thread.
 
> | The graph adressing, which will be certainly part of TMQL could be
> | re-used in the TMSL-T as well as in TMCL. Might be a new requirement
> | for TMQL to define the graph addressing part somehow independent
> | from the rest in a way that it can be easily re-used by other TM
> | standards.
> 
> What is graph addressing?

Well, I named it graph adressing to distinguish it from (XML) tree path 
addressing, because a TM is a graph and not a tree. Addressing is probably
not the best term here; maybe "matching" is more appropriate.
 
> * Lars Marius Garshol
> |
> | So it's not really a very big deal. An informal agreement would be
> | enough, I think. Or a joint technical report.
> 
> * H. Holger Rath
> |
> | I like the TR idea. But I assume that we will only come to the point
> | that we independently describe our two appoaches and solutions. And
> | it makes sense because both are somehow useful.
> 
> In that case two TRs are better than one, but I don't see why we
> shouldn't come up with a single way to do it. (The good thing is that
> those who make TMs can choose to support one or both of the solutions,
> since they don't collide with one another in any way.)

That's true. But I don't understand if you are in favor for one or 
two TRs now?

Regards,
--Holger

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