Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!dali.cs.montana.edu!milton!wex@dali.pws.bull.com From: wex@dali.pws.bull.com (Buckaroo Banzai) Newsgroups: sci.virtual-worlds Subject: Semantic space, "round 2" Message-ID: Date: 17 Aug 90 22:26:47 GMT References: <9007250107.AA01311@hitl.vrnet.washington.edu> Sender: hlab@milton.u.washington.edu Organization: Bull Worldwide Information Systems Inc. Lines: 96 Approved: hitl@hardy.u.washington.edu In article brucec%phoebus.phoebus.labs.tek.com@RELAY.CS.NET (Bruce Cohen;;50-662;LP=A;) writes: Problem being: if you didn't know you would want this information before the project started, do you have the tools to to extract it? Indeed. That is one of the reasons I sought a completely-general theory. At MCC we saw any number of tools fail for reasons including a too-limited ability to display the information they contained. In general, it takes a lot of work to put information into the system and people want to be well- rewarded for the time and effort they've put in. Conversely, you can have systems which are extremely flexible and general and fail because no one puts in enough useful information. That's more a sociological problem (though important to solve). Agreed, but that still doesn't address navigation, which is the nastiest of all the problems in my opinion. The whole reason for spatial metaphors is to allow users to apply their highly-evolved spatial perception and visualization systems to the navigation problem. These systems, though, are evolved to handle relatively circumscribed local areas, which may be somewhat, though not arbitrarily, cluttered (like the space in the branches of a temperate zone forest?). They break down in high-dimensional, large hyper-volume spaces. We don't as yet know what aids can help this, or how to optimally filter the perceptions of such spaces for easy navigation. True. The key is to *not* navigate in semantic space. That's too slow, cumbersome, and prone to error. There are reasons for doing it at times; they have to do with the merger between navigation and editing (another complex topic in itself). This, by the way, is the common error made by hypertext systems. They have the user navigate in the same space as the hypergraph is laid out, often restricting one to node-to-node travel. Highly inefficient and bewildering. The current best choice seems to be to "project" (in some sense not necessarily related to projective geometry) the navigation space onto some less complex space the user can handle, and provide disambiguation for the inevitable overloaded volumes. I think you need to consider this up front when investigating the spatial qualities of a cyberspace. No matter how interesting a space may be from the viewpoint of abstract organization, if users can't find their way through the maze, it's not a useful space. True, but if you can step out of the maze entirely and get an "overview" then navigation becomes much easier. Benedikt hinted at this same idea in his presentation at the cyberspace conference - his slides were highly artistic and conveyed as much of the "feel" as you can get from a static shot. I hope they will be reproduced in the book (but since they were color, they may be too expensive). The other key to navigation is to leave behind the methodology of linear movement. This is *very* hard, since that's how we move every minute of every day. But if we can learn to do things like teleport, use landmarks and so on, navigation becomes possible (if not yet easy). If the desired qualities of a space are determined by the objects within it, then it follows that different collections of objects should reside in different kinds of space. Maybe what we are calling cyberspace is just an anteroom filled with doors and rabbitholes into these spaces ... You're on the verge of discovering waypoints. Doors and rabbitholes are indeed the way to go. However, please remember that what I am describing is a theory that may be embodied in many different ways in different implementations. [I said:] There are lots of issues here, such as: what about ordering? what kinds of dimensions should there be? what about properties that are not confined to a single object, but are the result of object-interaction (such as the property earlier-version-of, an important concept in software engineering). [and got the reply"] Yes, please, I'd like to hear your thinking on all these issues. You don't ask for much, do you? OK, here's a quickie: I think that ordering is of two kinds: theoretical and practical. The theory of numbers tells us that the number one comes before the number two and so on. However, only a test of the processes in a queue can tell us that process one is before process two. You have to somehow let people know which kind of ordering they're seeing. I think there are several kinds of dimensions, more or less along the same lines as Will Bricken laid out in the posting that started all this. I think relational properties need to be represented, and are best done with extra-object annotations (such as arrows or lines between objects). I think there's lots more to say, but I haven't a lot of time. Sorry 'bout that. -- --Alan Wexelblat phone: (508)294-7485 Bull Worldwide Information Systems internet: wex@pws.bull.com "Politics is Comedy plus Pretense."