[topicmapmail] Wiki/WebLog application built on top of topicmaps...

[Thomas B. Passin]

[Lars Marius Garshol]\
> * Guy Murphy
> | The more choices is demonstrable simply by virture of an ADM I can
> | specify an arc pointing one way... I can *choose* to have an arc
> | pointing the other way in return if I so desire... I don't have this
> | choice with a topicmap...  whether this is a good, bad or
> | indifferent thing is a point of debate, but I have more choice for
> | modelling it would seem with the ADM.
> |
> | With a topicmap I am forced to have bidirectional arcs... this is
> | less choice, not more.
>

This is not quite so.  The asymmetry is expressed via the roles.  For
example, consider an RDF statement -

[dog#87] - owner -> [Harry]

This is unidirectional in the sense that the two ends of the arc can be
distinguished, so that we know which one is the subject.

In an equivalent topic map association, we would have

[dog#87] - {owned thing} - (owns) - {person} - [Harry]

This, people say, is "bidirectional".  What is the difference?  We have
spelled out the playing of the roles, making them potentially the subject of
other assertions.  The roles are still there (implicitly) in the RDF
version, except that somehow we are supposed to know about them, possibly by
reading a prose explanation of the predicate "owns".

In the topic map version, we certainly know that there is a lack of
symmetry, since the two roles are different.  We can decide which way should
be the default sense of this type of association if we want.  We can create
a template that identifies a preferred direction, use prose to capture it,
create a PSI and make the association type refer to it, or hardcode the
knowledge into our app.

True, it is a little more effort, but not much and virtually none for each
instance once you have the machinery in play.

Remember, adjusting an design to make some common operations more convenient
or faster is just like denormalizing a relational database for performance.
You still get to follow the underlying model, but you have a lot of
flexibility in how you implement it.

Cheers,

Tom P