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

[Thomas B. Passin]

[Guy Murphy]

> Well, one way link is managed, and visible from its point of origin....
it's
> worth consideration because it's simpler than having to think about how
> you're going to manage the filtering of a two-way link when you're only
> interested in the assertion from one side.
>
> Using an associative datamodel we wouldn't even be having this
conversation.
>
> I might assert "Guy Murphy" == "friend" ==> "Meg Ryan" ... and there's
> nothing useful to say about Megs role in this rlationship other than she's
> the subject of the assertion -- which importantly is implicit already in
the
> assertion -- because she doesn't even know of my existence. Nor is she
> likely to want to manage my assertion.
>
> It's nice to be able to express richly the roles of all participants
> involved in a relationship, but quite often there's nothing more useful to
> say than one participant is merely the subject or the assertion... at such
> times being forced to create a meaningful assertion the other way creates
> noise not any useful information....

You mentioned Semantica in your first post.  Semantica's model is, I
believe, equivalent to a subset of topic maps.  In Semantica, relationships
are not associative (which you said but is not really the case) and they are
bidirectional in a certain sense, but they have a different name for use
when you are viewing radially "outward" from a topic or radially "inward"
You could get that effect in a topic map association by having two names,
one in a "inward" scope and one in an "outward" scope.  You would
distinguish which topic is which by its role in the association.

With this approach, you could distinguish management metadata from
user-created metadata with ease - just scope the association.  As for the
case of [Bob]--(friend)--[Mary], is that not intrinsically a symmetrical
assocation?

If I were allowing user-created content in a TM, I would scope each
contribution by its user - of course, the user would be represented by a
topic on the topic map.  By using these scopes as filters, there could be a
"general content + this user only" view and another "general content + all
users less system metadata" view and a "system metadata" view (for
management) and a "see my own system metadata" view.

This shows some of the power of the full topic map model.  You have to put
in more work up front to get the machinery working completely (like
including scopes and (in this case) having different names for different
scopes), but once you have done that you can get a huge payoff.

As for "associative" relationships, you can still have them with TM.  You
just index the associations using an hash/dictionary/associative array.  You
will eventually want to index them anyway, to get performance once the map
gets large.  Make the index work for you.

> and that I think is an important flaw
> with topicmaps... noise.... I find they have a tendency to be noisy, and
> being able to indicate a direction to an association would be one way of
> helping to cut down that noise, especially with one-to-many relationships
> where the information is quiet and useful on one side, and noisy and
dilute
> on the other side.
>
Associations are by definition two-way (or more), but as I have sketched
above you can arrange for UI purposes to treat certain directions as special
if you want to.  A more interesting question is whether a relationship is
symmetric or not.  Semantica can maintain a marker saying whether an
association type is symmetric or not, but it does not seem to result in any
difference in the display in the reader.  A TM could just as well also say
whether an association type were symmetric or not (of course there are other
kinds of attributes a relationship can have, not just symmetry - why single
that one out?)

> Now with an associative model, with links going one way, one has the
option
> of asserting a link in the other direction... one can implement a topicmap
> ontop of the associative model... you have more options available to you
as
> a data modeller not fewer.
>
> As for managing relationships which are one way... you manage them from
the
> side making the assertion... which is the whole point, as the other side
> isn't interested in even seeing them, nevemind managing them.
>

Yup, just use make the creator into a scope and that is handled.

Cheers,

Tom P