Re: [topicmaps-comment] TMs & XTM [Was: skills to create topic ma ps]

["Thomas B. Passin" <tpassin@home.com>]

[Lars Marius Garshol]

>
> * Thomas B. Passin
> |
> | The main difficulty in hand-authoring topic maps is not syntax,
> ...
> | Similarly, it gets harder and harder to decide on what scopes to
> | create and apply, and you start to need help in seeing which ones
> | you have allready assigned to a name or occurrence.
>
> This I have not experienced. In fact, I've found scoping to be fairly
> easy to manage, but perhaps we use it in different ways.
>

It happens when you want to apply many scope topics to the same
characteristic.  Suppose you are collecting comments on a publication (as I
have actually done).  For comments against chapter 3, you apply scopes for
1) comments (to let you distinguish comments from all other topics in the
map), 2) chapter 3 (so you can review all comments for that chapter), 3)
topic maps, 4) logic, 5) the comment author (so you can review all the
comments by that author), 6) general readability, 7) .... and so on.

Later, you are looking at comments for Appendix A.  You may easily forget to
apply a scope for "comments" or for "comment author".  This inconsistency
makes it harder to find what you want by filtering on scopes.  This is a
realistic example of what I meant.

I say "realistic" because I actually made a topic map to help me review such
comments, and it was very helpful indeed.  In fact, it was the best approach
I've ever tried.  It helped me organize and review about one hundred
comments. It was a bit painstaking to create the map (I used my
Javascript/browser map tool that I've mentioned before and that helped a
LOT), but it was more than worth the trouble.

> | When the map gets bigger, you also find it harder to modify it -
> | especially deletions and corrections.
>
> This is also true. There is a limit to how far the text editing
> approach scales.
>
> | 2) Deciding how to model various kinds of information, ie.,
> | occurrences vs associations, and then being consistent about them.
> | This includes any reification you may be tempted to do.
>
> Absolutely. Modelling is a major issue, and no authoring solution is
> going to do it for you.
>

Right - that's why I said syntax isn't the major issue.

> | 3) Creating your ontology and being very clear about when something
> | is an instance vs. being a subclass of another topic.
>
> Isn't this the same as 2? Instance vs subclass does seem to be fairly
> difficult. I've found that a good rule of thumb when wondering whether
> B is a subclass of A to find some instance of B and then ask myself
> whether it's also an instance of A. If the answer is yes, then B is a
> subclass, if it's no it's not.
>
It's sort of the same, but there is another factor involved, based on my
personal experience at least.  There is a temptation to model a subclass as
a type, especially if you are not clear about the difference.  It is easier
and quicker to do and easier to get the data back out (just get the
instanceOf).   You can convince yourself that you know what you mean and
will do the right thing.  I'm talking here about inexperienced people, of
course, but those are the ones who are most lilely to be authoring by hand,
I would think, and they are people we want to get interested in topic maps.

So yes, it is a modeling issue, but it seems to me to also be a
psychological issue as well.

(Aside - I'd like to see subclassOf have a privileged position like
instanceOf does.  Yes, I know a purist approach would model an instanceOf as
an association when the map is built, but that's not the only way to do it.
Come to think of it, I suppose there is nothing to prevent your topic map
engine from treating subclassOf differently if it wants to, as long as any
XTM comes out right in the end).


Cheers,

Tom P