/[gzz]/manuscripts/FutureVision/referee-reply.txt
ViewVC logotype

Diff of /manuscripts/FutureVision/referee-reply.txt

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 1.6 by tjl, Thu Nov 13 21:44:54 2003 UTC revision 1.7 by benja, Thu Nov 13 21:52:17 2003 UTC
# Line 101  We have tried to do this. Line 101  We have tried to do this.
101  > article in its current form is still rather short and could easily  > article in its current form is still rather short and could easily
102  > accomodate more (\"real-world\") examples.  > accomodate more (\"real-world\") examples.
103    
104  We have added some more discussion about examples.  We have added a real-world example in Section 3.3.
105    
106  > The references you give are  > The references you give are
107  > applicable, but aren\'t sufficient.  > applicable, but aren\'t sufficient.
# Line 169  as well). Line 169  as well).
169  > Even in the description of applitudes there are still email bodies (which  > Even in the description of applitudes there are still email bodies (which
170  > seem remarkably free of items). Are these not \'files\'?  > seem remarkably free of items). Are these not \'files\'?
171    
172  This point is the same we discussed in relation to REVIEW 1, and possibly  This point similar to what we discussed in relation to REVIEW 1.
173  was what made us seem technophobic. We have made clearer what we meant.  We have made clearer what we meant. We have also added discussion
174    in Section 2 about the relationship between items and documents.
175    
176  > Section 2, sentence 1: delete comma after \"medium\"  > Section 2, sentence 1: delete comma after \"medium\"
177  > Section 2, para 5: planning should not be capitalised  > Section 2, para 5: planning should not be capitalised
# Line 206  propose to replace email and, e.g., acad Line 207  propose to replace email and, e.g., acad
207  because these are data that come to our system from the outside.  because these are data that come to our system from the outside.
208  It *is*, however, possible to *transclude* text from an email  It *is*, however, possible to *transclude* text from an email
209  into a new item, and have that item remain connected to the email  into a new item, and have that item remain connected to the email
210  through the transclusion.  through the transclusion. We have added discussion of this to
211    Section 2.
212    
213  > I receive 100 emails a day - convince me that this is a  > I receive 100 emails a day - convince me that this is a
214  > useful visualisation!  > useful visualisation!
# Line 224  No, not "the more, the more", but a reas Line 226  No, not "the more, the more", but a reas
226  Paper is useful, but paper notes are not easily connected to other  Paper is useful, but paper notes are not easily connected to other
227  paper notes.  paper notes.
228    
229    We have added a note to this paragraph.
230    
231  > Is this likely? Convince me that  > Is this likely? Convince me that
232  > you have thought this through rather than reciting Nelson\'s view. Have a  > you have thought this through rather than reciting Nelson\'s view. Have a
233  > look at the network diagrams from the early Intermedia papers on the  > look at the network diagrams from the early Intermedia papers on the
# Line 282  Fixed. Line 286  Fixed.
286  > Section 4.2.1: RDF visualisation is something which is not uncommon in the  > Section 4.2.1: RDF visualisation is something which is not uncommon in the
287  > semantic web. Please indicate how your approach differs from RDFViz  > semantic web. Please indicate how your approach differs from RDFViz
288    
289  Added discussion in section 5.4. Basically, RDFViz uses a plane  Added discussion in section 4.2.1 and 5.4.
290  embedding of the graph, we use a local subgraph.  Current approaches to RDF visualization use 2D layouts
291    that do not change when the user moves from node to node.
292    
293  > Figure 4: Since this is the principle illustration of the concept of  > Figure 4: Since this is the principle illustration of the concept of
294  > buoys, this diagram should be clearer. It currently is a mass of little  > buoys, this diagram should be clearer. It currently is a mass of little
# Line 312  This is, again, the scalability issues w Line 317  This is, again, the scalability issues w
317  Showing all persons on a map would make no sense as a visualization;  Showing all persons on a map would make no sense as a visualization;
318  showing the persons the user knows is a much smaller set and makes sense.  showing the persons the user knows is a much smaller set and makes sense.
319    
320  The user's space wouldn't contain the phonebook and even if it did,  The user's space wouldn't contain the white pages and even if it did,
321  showing the phonebook in that visualization wouldn't usually make sense.  showing them in that visualization wouldn't usually make sense.
322    
323  > Section 4.3: I\'m not sure what this description of the user interface  > Section 4.3: I\'m not sure what this description of the user interface
324  > library provides the rest of trhe paper.  > library provides the rest of trhe paper.

Legend:
Removed from v.1.6  
changed lines
  Added in v.1.7

savannah-hackers-public@gnu.org
ViewVC Help
Powered by ViewVC 1.1.26