[Gzz-commits] manuscripts/FutureVision referee-reply.txt visi...

[Benja Fallenstein]

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

Modified files:
        FutureVision   : referee-reply.txt vision.rst 

Log message:
        referee replies

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/manuscripts/FutureVision/referee-reply.txt.diff?tr1=1.6&tr2=1.7&r1=text&r2=text
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/manuscripts/FutureVision/vision.rst.diff?tr1=1.188&tr2=1.189&r1=text&r2=text

Patches:
Index: manuscripts/FutureVision/referee-reply.txt
diff -u manuscripts/FutureVision/referee-reply.txt:1.6 
manuscripts/FutureVision/referee-reply.txt:1.7
--- manuscripts/FutureVision/referee-reply.txt:1.6      Thu Nov 13 16:44:54 2003
+++ manuscripts/FutureVision/referee-reply.txt  Thu Nov 13 16:52:17 2003
@@ -101,7 +101,7 @@
 > article in its current form is still rather short and could easily
 > accomodate more (\"real-world\") examples. 
 
-We have added some more discussion about examples.
+We have added a real-world example in Section 3.3.
 
 > The references you give are
 > applicable, but aren\'t sufficient. 
@@ -169,8 +169,9 @@
 > Even in the description of applitudes there are still email bodies (which
 > seem remarkably free of items). Are these not \'files\'?
 
-This point is the same we discussed in relation to REVIEW 1, and possibly
-was what made us seem technophobic. We have made clearer what we meant.
+This point similar to what we discussed in relation to REVIEW 1.
+We have made clearer what we meant. We have also added discussion
+in Section 2 about the relationship between items and documents.
 
 > Section 2, sentence 1: delete comma after \"medium\"
 > Section 2, para 5: planning should not be capitalised
@@ -206,7 +207,8 @@
 because these are data that come to our system from the outside.
 It *is*, however, possible to *transclude* text from an email
 into a new item, and have that item remain connected to the email
-through the transclusion.
+through the transclusion. We have added discussion of this to
+Section 2.
 
 > I receive 100 emails a day - convince me that this is a
 > useful visualisation!
@@ -224,6 +226,8 @@
 Paper is useful, but paper notes are not easily connected to other
 paper notes.
 
+We have added a note to this paragraph.
+
 > Is this likely? Convince me that
 > you have thought this through rather than reciting Nelson\'s view. Have a
 > look at the network diagrams from the early Intermedia papers on the
@@ -282,8 +286,9 @@
 > Section 4.2.1: RDF visualisation is something which is not uncommon in the
 > semantic web. Please indicate how your approach differs from RDFViz
 
-Added discussion in section 5.4. Basically, RDFViz uses a plane
-embedding of the graph, we use a local subgraph.
+Added discussion in section 4.2.1 and 5.4.
+Current approaches to RDF visualization use 2D layouts
+that do not change when the user moves from node to node.
 
 > Figure 4: Since this is the principle illustration of the concept of
 > buoys, this diagram should be clearer. It currently is a mass of little
@@ -312,8 +317,8 @@
 Showing all persons on a map would make no sense as a visualization;
 showing the persons the user knows is a much smaller set and makes sense.
 
-The user's space wouldn't contain the phonebook and even if it did,
-showing the phonebook in that visualization wouldn't usually make sense.
+The user's space wouldn't contain the white pages and even if it did,
+showing them in that visualization wouldn't usually make sense.
 
 > Section 4.3: I\'m not sure what this description of the user interface
 > library provides the rest of trhe paper.
Index: manuscripts/FutureVision/vision.rst
diff -u manuscripts/FutureVision/vision.rst:1.188 
manuscripts/FutureVision/vision.rst:1.189
--- manuscripts/FutureVision/vision.rst:1.188   Thu Nov 13 16:43:35 2003
+++ manuscripts/FutureVision/vision.rst Thu Nov 13 16:52:17 2003
@@ -1098,7 +1098,7 @@
 
 Other RDF visualization packages we have found are
 of the graph drawing type: RdfViz [#rdfviz]_ and IsaViz [#isaviz]_, both based
-on the same 2D plane graph-drawing package (GraphViz, XXX) ,
+on the same 2D plane graph-drawing package [#graphviz]_,
 and
 Ontorama (`Eklund 2002`_)
 uses a hyperbolic-like planar visualization.