Re: Mapping files?

[Michel Biezunski]

>
> I am in favor of what you call "unintentionally hijacking topic maps".
> I think this is exactly what is needed for making topic maps fly
> and get widely used.
>
> Although we tried to develop a model which would be simple and
> straightforward, the remarks on this list lead me to think that
> the Topic Maps model as currently existing and embodied in the
> XTM/HyTm syntaxes might be *too* rich and *too* complex to
> correspond to various needs which would be happier with a lighter
> definition of topic maps.

Topic Maps are actually fairly complicated, if you try to include
everything.  For example, a scope can point to a topic in the map, a web
page, or a subject indicator.  At every turn, there are many, many things
you have to check for.  You cannot just relate topics, you have to put in a
role for each, and perhaps a member to hold the role (depending on how you
design the implementation).  And so on...

I am not saying they are __too__ complicated, but it is truly hard to
quickly and easily start using them, even more so withou a standard and
widely implemented query language.

It is even harder to modify an existing topic map than to create one.

What is the - or "a" - solution?  It can only be one of two kinds of things,
I think, if we want to make topic maps more accessible to beginners or
people who do not care about topic maps per se but might want to get
benefits from them?

First is to allow and specify simpler subsets, or perhaps allow isomorphic
subsets to make it easier to create and maintain simpler topic maps.  Second
is to create idioms or patterns, that would make it easier to have
standardized software to create and manage them.  These idioms would not
have the full flexibility that topic maps can bring, but for such uses you
do not want that.

For example, if you use a topic map to provide navigation among your web
pages, you only want a handful of topic, association, occurrence, and role
types.  Maybe you can avoid scopes altogether, depending on how you model
the site.  Maybe you do not need all the optional kinds of references (only
use topicRefs for occurrence types, say).  What you need is a UI that
creates all the behind-the-scenes topicmap-specific things, and that UI will
be much easier to create and use if there are few options.  It should be
able to output XTM for interchange purposes.

> That for me is a strong argument in
> favor of a modular perspective on topic maps, which would not
> contradict or invalidate anything that currently exists, but
> would make the learning curve simpler.
>

D'accord.

Cheers,

Tom P