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

[Lars Marius Garshol <larsga@garshol.priv.no>]

* Thomas B. Passin
|
| [difficulty of managing scopes]
| 
| 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.

It sounds to me like you have far too many scopes on your comments.
Thinking about it, this might be because your environment is
underpowered in terms of navigation/search, which leads you to
compensate by overusing scope. Does that sound right?

  1) This should be an occurrence type (or topic type), shouldn't it?

  2) If chapter 3 is a topic of its own that shouldn't be necessary,
     as the comment should be connected to chapter 3 directly, and
     therefore accessible from it.

  3) What do you mean by this?

  4) Is this the subject area of chapter 3? If so, it is a property of
     chapter 3, rather than of the comment, and should probably not be
     represented using scope.

  5) Sounds reasonable to me. If the comment is a topic, however, you
     could represent this as an association.

  6) Readability of the comment? Makes sense, although I am not sure
     what you would use it for.
 
  7) Kinda hard to comment 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 guess it is, and this is the kind of thing you want a schema
language for, so that it can tell you that you've forgotten
something. 

| 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.

Why did you use your own browser tool instead of the Omnigator? I am
just curious, especially as it seems to me that some of the things you
do with scope would have been easier without it when using the
Omnigator. 
 
* Lars Marius Garshol
|
| Absolutely. Modelling is a major issue, and no authoring solution is
| going to do it for you.

* Thomas B. Passin
|
| Right - that's why I said syntax isn't the major issue.

Well, if it's a major obstacle, then it is the major issue, since it
keeps you from doing any effective work at all. Once you've overcome
the syntax problem modelling becomes the next major issue. 
 
* Lars Marius Garshol
|
| 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 is 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.

* Thomas B. Passin
|
| There is a temptation to model a subclass as a type, especially if
| you are not clear about the difference.  

What do you mean by this? Any class is by definition a type, whether
it's a superclass or a subclass. Do you mean an instance? If so you
seem to be the opposite from most people, who in my experience overuse
subclassing. 

| 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. [...] So yes, it is a
| modeling issue, but it seems to me to also be a psychological issue
| as well.

Actually, it seems to me to be a consequence of people using the wrong
tools. As long as you don't work with the syntax directly (and you
should in any case not) this is no problem.

I may sound like a broken record here, but people really should not
work with the syntax directly. It's just going to lead them into lots
of problems like this one. It's much much easier to work with an API
where the topic map has been properly digested for you, and the
difficult things are taken hand of by someone else, and you can just
make use of the result.

I'm not sure to what extent this applies to you, Tom, but for the rest
of you who feel tempted to use XSLT or similar things: just don't. Use
TM4J, tmproc, or XTM:Base instead.
 
| (Aside - I'd like to see subclassOf have a privileged position like
| instanceOf does.

There were several conflicting opinions about this and instanceOf
during the design of XTM 1.0, but in the end a different decision was
taken, and I think it was the right one. And for once the rationale is
publicly available:

<URL: http://www.doctypes.org/xtm/syntax/Ontopia-syntax-comments.html#TOPIC >

| 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).

That's correct. On the other hand, the cost of maintaining a
collection of superclasses (or subclasses) for every topic is not
insignificant, and it's not really necessary, either. What Ontopia has
done is to provide a utility API that lets you traverse the class
hierarchy as if it were represented directly, but still represent it
using associations. This has turned out to work very well.

--Lars M.