[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [topicmaps-comment] TMs & XTM [Was: skills to create topic ma ps]
[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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC