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

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

[Lars Marius Garshol]


>
> * 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?
>

No, It's a conceptual and modeling matter.  I am thinking here of a scope as
a context within which I choose to consider a topic.  Thus, a topic (here a
comment by a reviewer) may have some text as an occurrence, and may also
have that author as an occurrence. But I can choose to think of that comment
in the context of "logic", "readability", "topic maps", and so on.  I don't
see those things as occurrences of the topic - i.e., addressable or literal
information about it.

Now I could assign many occurrences of type, say, "keyword" or "category" to
that topic, but that is not really what occurrences are for.  In contrast,
the scope mechanism is exactly the right thing.  From the XTM Rec, for
example:

"It [scope] establishes the context in which a name or an occurrence is
assigned to a given topic"

In fact, I consider that the ability to apply scopes for this kind of
purpose is one of the strengths of topic maps.  They are potentially more
than just keywords because scopes can potentially have semantics, via their
topic types (although I don't use that ability in this case).

I could also have dismembered the review comments into finer grain features,
and used occurrences like "comment_about_logic", but again, that wouldn't
let me collect them according to different contexts.

I  could also have assigned those same scopes to the occurrence that
contains the text of a comment (each comment is of course represented by a
topic of its own).  My app would allow this.  But then there is a user
interface problem - you want to scan a list of topics, choose one, and see
what it contains.  It would be harder to scan a list of occurrences and pick
out the desired ones - at least it would be harder for a person, perhaps not
for a machine.

That would also require yet another one or more user interface elements (you
need a list of topics anyway, so you can't get rid of that one in favor of
the other).  However, the last word has not been written about this yet, not
by a long way.

>   1) This should be an occurrence type (or topic type), shouldn't it?
>
I want to be able to list (so I can select one to look at, for example) the
names of all topics whose subject is a comment, and no others.  That's not a
function of their occurrences.  It could be a matter of their topic type,
but why single out this one thing when there are other ways I want to list
them as well?

>   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.
>
Yes, I do have a chapter 3 association, and all comments about chapter 3 are
role-players in it.  But sometimes you want to list associations, and
sometimes you want to list topics.  I also applied some scopes to the
associations (although I found that I haven't needed to use them yet because
using the scopes applied to the topic names has been powerful enough ).

>   3) What do you mean by this?
>
There were some review comments about the subject of topic maps.

>   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.
>
No, the subject of "logic" appears across many chapters.

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

Yes, I do have an association of each comment author.  I have found, though,
that it was very useful to also have a scope for the authors - it's a matter
of helping one to focus attention (by narrowing down the number of things to
look at), and also being able to rapidly switch to a wider view (by removing
a scope from the filter).

>   6) Readability of the comment? Makes sense, although I am not sure
>      what you would use it for.
>
Because I wanted to see if there were consistent comments about readability,
so I needed to be able to see them all grouped together as much as possible.
That could help be address them.

>   7) Kinda hard to comment on. :-)
>

:-) There were more like those ...

> | 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.
>
Right on. Also, remember that this thread started off about issues for
hand-authoring maps.

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

1 - There is no authoring help with Omnigator, and my app does author maps.
2 - I can change my app.  In fact, it's really a testbed for discovering how
to interact with topic maps, and it's quite nice for that.
3 - Omnigator is too expensive for my personal use (this is a personal
project) and getting a new trial version every month or two could put me in
a hole if that didn't work out.  Besides, I think that would be an abuse of
the idea of a "trial" version.  This supported actual substantial work of
mine, and this goes well beyond just doing "evaluation".
4 - Omnigator's way of applying scope as filters doesn't do what I want.  In
fact, I consider it to be non-intuitive.  If I ask to filter by some scope,
I don't want to see a topic that doesn't have that scope, but Omnigator acts
some other way.  I'm sure there's a good reason for this, but it isn't
useful for what I want to do.

Of course, I evolved my app as I went along.  At the end I exported my topic
map to xtm and ran it in Omnigator (as you know because I found a bug that
the latest version turned out to have fixed).  Omnigator was pretty good
(especially the version that times out this month), but still not as
convenient as mine for navigating the map the ways I want to, and in seeing
grouped information.

(As an aside, the version of K42 I had at the time couldn't display my map -
not that it threw an exception, but it just didn't display much.  I think
that K42 requires certain internal linkages to specific PSIs, which my map
does not use.  I think it also requires specific things for association
members and roleplayers that are not required by the TM Rec, and that my own
maps do not have.

Whatever it is that K42 wants to see, it improves the display of
associations, for example, when the map is prepared correctly, but makes it
much less usable for legal maps that are not constructed according to
expectations.

I apologize to K42 people if I have misunderstood things, but the fact
remains that the version of K42 that I had in November couldn't really
display my maps.  I'd suggest finding a way for it to be less demanding
about how a map is cosntructed).

One thing that operates in my app's favor is that I keep the entire map in
memory in the browser, so I don't have to go to a server.  There are some
disadvantages to this, but it's great for its purpose of experimentation.

In favor of Omnigator (and let's not leave out K42!) is speed - the java
engine at the server is going to be much faster than javascript in the
browser - and correspondingly being able to handle a much larger map.

If you like, we can have an off-list discussion about this.  As I said, one
of the main purposes of my app is to make it easy to experiment with
interfaces, and I think that is starting to pay off.

Another purpose is to make it easy to experiment with idioms for topic maps.
I think we need much more work with idioms, as I mentioned a few days ago in
another post.  For one thing, your idiom strongly affects how the interface
and search mechanisms need to work.

Cheers,

Tom P