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

[Guy Murphy]

Hi.

Thanks for the reply Lars, replies are inline.

[snip]

> * Guy Murphy
> |
> | I'd like to tentatively announce a Wiki/WebLog application built on
> | the .NET platform using a TopicMap[-like] back-end, for anybody that
> | might have an interest.
>
> This sounds very interesting. I'll have a look when I'm online again.
> For now the "[-like]" part of what you write sounds a bit disturbing.
> Why make it 50% topic maps? Why not 0% or 100%? I have difficulty
> seeing the benefit of doing it any other way.

Well, I'm a one-man-band on this project and so for version 1 am more
interested in getting something implemented so I can get a set of
requirements for version 2 that's more grounded in reality.... saying
"topicmap-like" does two things... it gives me a big emergency exit... and
it warns people that the objective of the application isn't to implement a
topicmap engine.

I've worked with topicmaps in the past so my production of the datastore was
heavily influenced by my exposure to topicmaps.

> Do you implement XTM import and/or export? If not, why not? And, if
> not, what's the relationship between your Wiki-like thing and topic
> maps?
>

There is no XTM import, but this is because it simply hasn't been done. Not
because it can't be done.

I produced a DMoz import and a partial XFML import for the purposes of
bulk-loading the datastore for testing, not out of any desire to work with
those formats at this time.

At some point there will be XTM import and export, (and quite possibly
complete XFML support), but they aren't high on my list of priorities, and
currently I'm not sure what degree of information loss (if any) there might
be in importing XTM from another application into Conclave.

This isn't for any lack in the XTM standard (although there are things I
like more and less through the standard), but simply because I never set out
to provide a datastore implementing XTM... it's a tertiary (although not
unimportant) consideration if you like.

In all liklihood toward the later part of the year I will either decided
topicmaps are worwhile enough to produce a faithful implementation, or I'll
bin consideration of topicmaps completely.... it's a learning process for
me.... the liklihood is that I'll sit down with the specs processing model
for version 2 and simply implement a compliant XTM datastore.

I simply dont know at this stage until I use Conclave for a bit and get an
appreciation of the stupid things I did, or missed, and what Conclave more
properly needs for a datastore.... I'm now a firm believer of JustDoIt, and
figure out what I should have done different as I go along. I got tired of
agonising over design choices =)

> | I say TopicMap[-like] as the back-end doesn't implement some of the
> | fine-points of the TopicMap model... associations aren't topics for
> | instance... but it has topics, occurrences, associations etc.
>
> Well, associations aren't topics in topic maps, either, so I wonder
> what you mean by this. If you want to know how to implement topic maps
> in your back end, look at the SAM:
>   <URL: http://www.isotopicmaps.org/sam/ >

Then I've misunderstood aspects of the spec, as I was under the imprecion
that associations were addressable as topics... I've just got back into
London and am in a flap at the moment... I'll revisit the spec and give a
more considered reply on the subject when I've half an idea as to what I was
thinking in the first place.

The last time I was in confused discussion on a topicmap list it was while
being told that associations fundamentally had to be addressable as topics
otherwise there was a whole scope of model that can't be expressed (quite
correctly).

> | The application is very close to beta now, with most major features
> | being complete I am currently working on DateTime associations [...]
>
> Why model this as associations rather than occurrences? That way you
> don't have to create lots of topics you don't really need.

I'm inclined to agree with you on this matter... one of the things I'm
finding I'm learning most about is what's a god candidate for an occurence
and what isn't. I ceratinly wouldn't argue with you on the suggestion, I
intend to implement both and suck it and see.

The reason why I'm considering DateTime related topics, is I want people to
be able to go to Febuary 14th 2003 and to be able to see what was altered on
Conclave on that day. It also makes it easy to construct calendars that way.

> | As a side note if I were to do this application again I would choose
> | an Association DataModel rather than a TNM one for the reason that
> | I've found that an annoying aspect about enforcing bidirectional
> | relationships is that one side can't be uninterested in the
> | relationship. By way of concrete example...
>
> Note that topic maps are called "topic maps", not "topic navigation
> maps". That name went out of use back in 1999.

You're correct, and I'm aware of that, but I like Topic Navigation Maps, as
the "Navigation" is of core interest to me and emphasises my interest in use
of topicmaps for constructing a view around a given point, over say
topicmaps more for querying... in short I didn't agree to drop the
"Navigation" even if you did =)

> | We have a simple relationship of... created(user, topic)... which is
> | formed between a topic representing a user and the topics they
> | create.
> |
> | Now 100 topic creations later, each topic that's created has a
> | single highly useful link by virtue of the "created" association to
> | the user that created it... the user on the other hand has 100
> | "created" associations from their topic, 95 of which they aren't
> | remotely interested in.... Now I'm aware that others might be
> | interested in what topics a user has created, but I'm looking to
> | fulfil pragmatic user requirements not purity of form.
>
> That's fine, but why is this a problem. You don't have to display
> these relationships when we are looking at a User topic. You can just
> filter them out, put them on a separate page, or do whatever you like.
> So how does this become a

I can do whatever I like with the topics when handling them as special
cases. And indeed some topics and relationships (such as comments and weblog
entries) are handled as a special case. I also want to to be able to handle
a general case of topic/assoc display for general navigation purposes, where
general desire to filter from one end of an assoc or 'tother is declared as
part of the map.

In conclave one doesn't look at a "User" topic, one just looks at a topic.
Likewise the topic that allows you to edit topics is just another topic
"EditTopic", it's not a special case, neither is "DisplayAssoc",
"CreateUser" etc etc. Topics contain control specs as part of their
occurence data that present forms for editing... these controls are
meaningful to the Web application Conclave, but have no part of the
datastore... etc, but the topics themselves are all equal, and all points
within Conclave are equal, first class navigation end points.

I'm not sure if I've made any sense it that, but more broad desire/goal is
as much as is possible (and I'm happy to admit defeat if I need to) avoid
special cases in topic navigation and display where possible.

> | It would seem that the Associative DataModel (such as that used by
> | Semantica) offers me more choices than the TopicMap.
>
> How?

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.

I have personally hit a situation where in a given case it would be cleanest
to implement a relationship with a directional arc. That is an arc with a
single role, pointing one way... yes there are ways I can filter, or express
scope, or otherwise get around the matter as I could in serveral other
models including a relational one... the fact is that this developer (quite
possibly mistakenly) wishes he had a choice to express a relationship going
one way, with no relationship expressed in return.... declared thus, not
implictly interpreted thus.

If I'm missing something in the spec that allows me to express a directional
association *simply*... or even a weighted association would do, expressing
a 0/1 relation of weights is good enough for my purposes... but I'm missing
it if it's there.

Having said all that, I need to sit down with the spec again this weekend
again, as I haven't read the spec since I last posted to a topicmap list
which was many months ago.

>
[snip]

I appreciate being challenged on these issue though, as it stops me drifting
off into the ether and reinventing wheels needlessly.

Cheers
    Guy.