[Gzz-commits] manuscripts/FutureVision oplan.txt

[Benja Fallenstein]

CVSROOT:        /cvsroot/gzz
Module name:    manuscripts
Branch:         
Changes by:     Benja Fallenstein <address@hidden>      03/11/13 11:46:06

Modified files:
        FutureVision   : oplan.txt 

Log message:
        contrast loom with other rdf visualization

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/manuscripts/FutureVision/oplan.txt.diff?tr1=1.17&tr2=1.18&r1=text&r2=text

Patches:
Index: manuscripts/FutureVision/oplan.txt
diff -u manuscripts/FutureVision/oplan.txt:1.17 
manuscripts/FutureVision/oplan.txt:1.18
--- manuscripts/FutureVision/oplan.txt:1.17     Thu Nov 13 11:07:46 2003
+++ manuscripts/FutureVision/oplan.txt  Thu Nov 13 11:46:05 2003
@@ -164,7 +164,19 @@
 Views: Move [#multiple-views-refs] from note to main text.
 
 Views are independent of connections, unlike in systems
-like OHM where the document type determines the view [9]
+like OHM where the document type determines the view [9]:
+
+    Note that connections are made to items, not to
+    particular views of items. One can view the same item
+    using different views, yet its connections stay the same
+    in each case. Also, while the network of items can be versioned
+    (by keeping a version history), views of it are not.
+
+    [[maybe put this in note -- yes, probably]]
+
+    [[XXX maybe say more like
+    If you told the system to go backwards or forwards in time,
+    it would ]]
 
 ...
 
@@ -215,9 +227,19 @@
     subject and the object and with the predicate as its label.
 
     While the zzstructure is simple to browse locally,
+    because it has higher-level (user-centred) semantics,
     programming is often easier in RDF, because many-to-many
     relationships can be represented more naturally.
 
+    As an example, consider making a list of attendants of a meeting.
+    In RDF, these would be connected directly for the meeting.
+    In zzstructure, the meeting would be connected to the first
+    attendant, and on a different dimension, the first attendant
+    would be connected to the second, the second to the third,
+    and so on. Removing one attendant from the set is not as
+    straight-forward as in RDF (you need to special-case
+    the case of the first attendant being removed).
+
     Using RDF as a hyperstructure, items are nodes. 
     Two data structures can independently connect information
     to the same item by using different properties. Properties
@@ -298,10 +320,31 @@
 Emphasize that we're doing that is different from all other
 RDF visualizations we know, including Ontorama!
 
+    No attempt is made ... on and off.
+
+    This is entirely different from existing
+    RDF visualization tools, which create
+    a fixed 2D layout for a graph (sometimes shown in a distorted,
+    hyperbolic-like view), and then only allow
+    the user to zoom and scroll through it.
+
 (or move related to 5.4?) [24],[26]
 
 Also details about how to handle large numbers of neighbours
-belong here. [6]
+belong here. [6]:
+
+    If there are too many connections along the active
+    relationship types, we show only as many as fit on the screen
+    and allow the user to scroll through the list. To make this fast
+    even for very large lists, we plan to employ fisheye sampled
+    lists (Furnas 1997), in which every element of 
+    an n-elememnt list can be reached with O(log(n)) clicks.
+
+    ADD TO REFERENCES:
+
+    Furnas, George W., Effective View Navigation. 
+    In Human Factors in Computing Systems CHI '97 Conference Proceedings, 
+    ACM, 1997, 367-374
 
 
 4.2.2 Buoys
@@ -616,6 +659,12 @@
 5.6 Fluid Links and Transpointing Windows
 -----------------------------------------
 
+
+
+6 Concl
+=======
+
+Delete last, bracketed sentence.
 
 Acknowledgements
 ================