[topicmapmail] multidirectional property of associationrole

[Lars Marius Garshol]

* H. Holger Rath
| 
| When we are talking about IDs I don't care how they look like. They
| are for the computer - humans deal with names ;-)

Very much agreed. :-)
 
* Lars Marius Garshol
|
| [the use of scope to name association types/roles]
|
| It does, and I'm glad this is finally being discussed in the
| open. We should thrash this out, and then just all use a single
| solution. It's much better for all of us that way.
 
* H. Holger Rath
|
| I agree. But I have the feeling that there are not only at least 
| two solution proposals on the table (Ontopia's and empilis') but
| also two approaches how to use the acrs.

That could be. If so I guess we still have a choice to make, but it
becomes more involved.
  
* Lars Marius Garshol
|
| Well, you can't reliably produce sentences in a generic topic map
| navigation tool. You may get it to work in some cases in English, and
| maybe even German, but for Japanese and other non-indo-european
| languages it just won't work. (Try Kiwai, for example.  <URL:
| http://www.krysstal.com/langfams.html > :-)
 
* H. Holger Rath
|
| You're probably right -- I am not an language expert. But when you
| look at the internet (and that is probably the main market for topic
| maps) what is the mainly used language?

So what? Text generation doesn't work reliably for English either, at
least not without schema knowledge.

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

| 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.
  
* Lars Marius Garshol
|
| The solution you propose requires nē - n + 1 names, where n is the
| arity of the association. 
 
* H. Holger Rath
|
| It is n*(n-1). But you're right. It 'explodes' when you have more than
| three roles.

n*(n-1) is the same as nē-n, so the difference between us seems to be
that I count the unscoped name of the association as well. (Well,
actually Steve figured out the formula first.)
 
* Lars Marius Garshol
|
| For 4-ary associations that's 13 names. One of our customers uses
| 13-ary associations...
 
* H. Holger Rath
|
| I assume this could be factorized down and you use this only for
| easier maintance having everything in a single assoc. Could give us
| a hint what is expressed with 13 role?

You are right that it could be factorized down, and personally I think
it ought to be. We have offered this customer ontology design
training, but they have so far not accepted, IMHO to their disadvantage.
 
* Lars Marius Garshol
|
| The XTM example you gave was not complete, BTW.
 
* H. Holger Rath
|
| Not complete in which sense (it was manually created)? I left out
| the assoc instance - the example listed the type and role topics.

It also left out some of the role names, I think.
  
| 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...
  
* 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).  
The TMSL-FO thing doesn't seem necessary to me. Surely XSL:FO can do
that job?

| 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?
 
* 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.)

| I would like to see that someone from Mondeca comments on this issue
| as well.

Me too.

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