/[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.2 by tjl, Thu Nov 13 20:19:25 2003 UTC revision 1.3 by tjl, Thu Nov 13 21:30:08 2003 UTC
# Line 10  Line 10 
10  > about\" and not files or documents. I would wager most people in fact do  > about\" and not files or documents. I would wager most people in fact do
11  > map files to \"cared about things\" fairly closely.  > map files to \"cared about things\" fairly closely.
12    
13    Thank you; our original argument was indeed flawed. We have removed
14    our original claims about files and directories in favor of discussion
15    about how our work
16    
17  We have clarified our explanation of this - our original expression  We have clarified our explanation of this - our original expression
18  was not good.  was not good.
19    
# Line 23  for meetings, people, places, ... Line 27  for meetings, people, places, ...
27  > academic paper. I think the paper could be improved by recasting it in a  > academic paper. I think the paper could be improved by recasting it in a
28  > more academic tone and less like you are trying to sell something.  > more academic tone and less like you are trying to sell something.
29    
30  The use of bold and writing scannable text is what the JoDi guidelines  The use of bold and writing scannable text is what the JoDI guidelines
31  themselves recommend, so we have kept them.  themselves recommend (refering to Nielsen's guidelines for
32    writing for the Web), so we have kept them.
33    
34  > I\'m familiar with Nelson\'s assertion that structure needs to be  > I\'m familiar with Nelson\'s assertion that structure needs to be
35  > visualized, but as far as I know, this is still very much an assertion,  > visualized, but as far as I know, this is still very much an assertion,
# Line 40  This is also something we have tried to Line 45  This is also something we have tried to
45  We only show the currently focused item and the items that are close  We only show the currently focused item and the items that are close
46  to it in the network of items. The local degree of the item graph  to it in the network of items. The local degree of the item graph
47  is not terribly high; if it is, it can be adjusted to a more reasonable  is not terribly high; if it is, it can be adjusted to a more reasonable
48  structure. For example, if there are 1000 meetings with carli, they'd  structure. For example, if there are 1000 meetings with Carli, they'd
49  probably be categorized to meetings about paper A, meetings about research  probably be categorized to meetings about paper A, meetings about research
50  grant B, ...  grant B, ...
51    
# Line 108  Several references have been added. Line 113  Several references have been added.
113  > (U. Patras) is probably better illustrative of the point it looks like you  > (U. Patras) is probably better illustrative of the point it looks like you
114  > were trying to make, since it\'s both earlier and more general.  > were trying to make, since it\'s both earlier and more general.
115    
116    Thank you, we hadn't seen that article.
117  We have added this reference.  We have added this reference.
118    
119  > As an aside, I gave this paper to one of my grad students to read, who had  > As an aside, I gave this paper to one of my grad students to read, who had
# Line 130  The discussion above, about these concer Line 136  The discussion above, about these concer
136  > own experience of zzStructure and latterly RDF, they should concentrate on  > own experience of zzStructure and latterly RDF, they should concentrate on
137  > developing their own story about the work that they do instead of  > developing their own story about the work that they do instead of
138  > recycling the (rather technophobic) Nelson account.  > recycling the (rather technophobic) Nelson account.
139  >  
140    As a matter of opinion, we don't consider Nelson technophobic but
141    rather "bad-techno"-phobic..
142    
143    We have tried to smooth over some of the more controversial expressions,
144    as related to denigrating files and directories, as mentioned
145    in the reply to REVIEW 1.
146    
147  > In particular, I believe that there is the basis of some really  > In particular, I believe that there is the basis of some really
148  > interesting Semantic Web work here, where item-based editing and display  > interesting Semantic Web work here, where item-based editing and display
149  > is just one application of in terms of application-neutral, semantically  > is just one application of in terms of application-neutral, semantically
150  > modelled data.  > modelled data.
151  >  
152    We have added a mention of this to the FenPDF section.
153    
154  > The presentation of the paper though is currently too bitty - too many  > The presentation of the paper though is currently too bitty - too many
155  > unelaborated claims interspersed with irrelevant technical details.  > unelaborated claims interspersed with irrelevant technical details.
156  >  
157  >  We have tried to address this as best we can.
158    
159  > Specific Comments--  > Specific Comments--
160  > Abstract: if we build systems structured around things we care about,  > Abstract: if we build systems structured around things we care about,
161  > would that necessarily help us organise our lives?  > would that necessarily help us organise our lives?
162  >  
163    Changed to explicitly mention that this is conjecture (as per REVIEW 1
164    as well).
165    
166  > Introduction: instead of being centred around files/directories...center  > Introduction: instead of being centred around files/directories...center
167  > around the things we care about. But surely we will always need to develop  > around the things we care about. But surely we will always need to develop
168  > abstractions for aggregation? Will they not be similar to directories?  > abstractions for aggregation? Will they not be similar to directories?
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
173    was what made us seem technophobic. We have made clearer what we meant.
174    
175  > Section 2, sentence 1: delete comma after \"medium\"  > Section 2, sentence 1: delete comma after \"medium\"
176  > Section 2, para 5: planning should not be capitalised  > Section 2, para 5: planning should not be capitalised
177    
178    Done
179    
180  > Section 2, para 6: \"we propose to build\" - why not just make items the  > Section 2, para 6: \"we propose to build\" - why not just make items the
181  > user interface paradigm? Why not still have files and directories  > user interface paradigm? Why not still have files and directories
182  > underneath?  > underneath?
183    
184    We have added a note: this is possible, of course, but we have chosen
185    not to do so, because the files and directories underneath are not stable;
186    we want our system to store information reliably, and integration of such
187    reliability with a filesystem is quite problematic.
188    
189  > Figure 1: the diagram shows 1 item (person) under focus. However, the suer  > Figure 1: the diagram shows 1 item (person) under focus. However, the suer
190  > may know hundreds of people - dozens with some form of relationship to  > may know hundreds of people - dozens with some form of relationship to
191  > Carli. Some of the earliest hypertext systems attempted to make use of  > Carli. Some of the earliest hypertext systems attempted to make use of
192  > similar maps - and failed. Explain why your system won\'t have the same  > similar maps - and failed. Explain why your system won\'t have the same
193  > failings.  > failings.
194    
195    We have tried to explain this in detail in section 2. The views
196    are not static maps - they are
197    dynamic and the user can interactively scroll and adjust various parameters.
198    We also discuss various reasons why such a high number of connections
199    should not occur in realistic uses of this system.
200    
201  > Figure 2a: Where are the items *inside* the email? Is the email just a  > Figure 2a: Where are the items *inside* the email? Is the email just a
202  > file of content? I receive 100 emails a day - convince me that this is a  > file of content?
203    
204    The email in the example is just text, like email today is. We do not
205    propose to replace email and, e.g., academic articles by several items
206    because these are data that come to our system from the outside.
207    It *is*, however, possible to *transclude* text from an email
208    into a new item, and have that item remain connected to the email
209    through the transclusion.
210    
211    > I receive 100 emails a day - convince me that this is a
212  > useful visualisation!  > useful visualisation!
213    
214    This is related to the discussion about item overload we have addressed
215    above.
216    
217  > Final 2 paragraphs of section 2 - you claim that paper isn\'t useful to  > Final 2 paragraphs of section 2 - you claim that paper isn\'t useful to
218  > help us organise our thoughts, but that a hyperstructure will be. Your  > help us organise our thoughts, but that a hyperstructure will be. Your
219  > claim seems to rest on the idea that the more interconnections there are,  > claim seems to rest on the idea that the more interconnections there are,
220  > the more organised everything will be. Is this likely? Convince me that  > the more organised everything will be.
221    
222    No, not "the more, the more", but a reasonable amount of interconnections.
223    
224    Paper is useful, but paper notes are not easily connected to other
225    paper notes.
226    
227    > Is this likely? Convince me that
228  > 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
229  > look at the network diagrams from the early Intermedia papers on the  > look at the network diagrams from the early Intermedia papers on the
230  > Victorian web.  > Victorian web.
231  >  
232  >  A fundamental difference between the Intermedia views and our work
233    is that in the maps we saw, for example, in Utting's article,
234    *icons* are used to represent the different nodes around the
235    given node.
236    
237    This is something that we do differently: for example, in FenPDF
238    an article is never represented by something other than itself.
239    There is no icon, no filename, nothing like that to add to the cognitive
240    load of the user. Rather, it is always the picture of the article itself,
241    or a fragment. The unique backgrounds make this an especially
242    useful alternative, since for familiar articles, you can recognize
243    them at a glance.
244    
245    All this is made possible by the increased graphics processing power
246    offered by modern OpenGL accelerators.
247    
248    The difference is to us so obvious that we forgot to mention
249    it explicitly in the article, but a very important one, we feel.
250    
251    We have discussed this in the new section 5.4 (we noticed that
252    we had a numbering error in the orig. manuscript so the section
253    numbers haven't changed ;).
254    
255  > Section 3.1: an illustration of the zzStructure might be useful,  > Section 3.1: an illustration of the zzStructure might be useful,
256  > especially if it could be compared with an RDF structure in 3.2  > especially if it could be compared with an RDF structure in 3.2
257    
258    Added.
259    
260  > Section 3.2: zzStructure is simpler to browse locally because it has  > Section 3.2: zzStructure is simpler to browse locally because it has
261  > higher-level (user-centred) semantics.  > higher-level (user-centred) semantics.
262    
263    A good point, we have added this and acknowledged the referee.
264    
265  > Section 3.2: How does the many-many relationship change the data  > Section 3.2: How does the many-many relationship change the data
266  > structure?  > structure?
267  >  
268    We have added discussion of this.
269    
270  > Section 4: comments on the internal architecture (relatively monolithic -  > Section 4: comments on the internal architecture (relatively monolithic -
271  > is this an oxymoron?) seem out of place, and are also not well explained.  > is this an oxymoron?) seem out of place, and are also not well explained.
272    
273    The comment is removed, it was explaining a shortcoming
274    of our current prototype, not the vision.
275    
276  > Section 4.1: Nelson used the word intertwingled to describe a complex  > Section 4.1: Nelson used the word intertwingled to describe a complex
277  > semantic interconnection. Please don\'t use it just to mean  > semantic interconnection. Please don\'t use it just to mean
278  > \'interconnected\' or similar.  > \'interconnected\' or similar.
279    
280    Fixed.
281    
282  > 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
283  > semantic web. Please indicate how your approach differs from RDFViz  > semantic web. Please indicate how your approach differs from RDFViz
284    
285    Added discussion in section 5.4. Basically, RDFViz uses a plane
286    embedding of the graph, we use a local subgraph.
287    
288  > Figure 4: Since this is the principle illustration of the concept of  > Figure 4: Since this is the principle illustration of the concept of
289  > 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
290  > thin lines.  > thin lines.
291    
292    This is a figure from
293    that illustrates where the concept originates in the graphical
294    language of drawing technical diagrams.  It is an authentic
295    figure from NASA and changing it would make, to us, no sense.
296    The full version of the figure (accessible by clicking the
297    shrunken version in the image) is clearer than the reduced one.
298    
299  > Figure 5: Although I think I understand what the figure should be showing  > Figure 5: Although I think I understand what the figure should be showing
300  > me, I can\'t see it in the screenshots themselves.  > me, I can\'t see it in the screenshots themselves.
301    
302    We have tried to make the graphics a little clearer, especially
303    in the full version of the image.
304    
305    
306  > End of section 4.2: the example of a map with a buoy for every person who  > End of section 4.2: the example of a map with a buoy for every person who
307  > lives there kind of invites a very probing question - can you handle 1  > lives there kind of invites a very probing question - can you handle 1
308  > million buoys? Can the user? Is this a fundamental problem with items -  > million buoys? Can the user? Is this a fundamental problem with items -
309  > just too many of them to handle?  > just too many of them to handle?
310    
311    This is, again, the scalability issues we have addressed above.
312    Showing all persons on a map would make no sense as a visualization;
313    showing the persons the user knows is a much smaller set and makes sense.
314    
315    The user's space wouldn't contain the phonebook and even if it did,
316    showing the phonebook in that visualization wouldn't usually make sense.
317    
318  > 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
319  > library provides the rest of trhe paper.  > library provides the rest of trhe paper.
320    
321    We have considerably revised this section to make its relationship
322    clearer.
323    
324  > Section 4.4: This seems to be potentially the most exciting part of the  > Section 4.4: This seems to be potentially the most exciting part of the
325  > paper but I think that too little has been made of it. Develop a scenario  > paper but I think that too little has been made of it. Develop a scenario
326  > of the use of FenPDF for understanding or organising academic literature  > of the use of FenPDF for understanding or organising academic literature
327  > (tie it back to the major objectives of the apper outlined in the  > (tie it back to the major objectives of the apper outlined in the
328  > introduction). At the moment it is simply a too-brief demonstration of a  > introduction). At the moment it is simply a too-brief demonstration of a
329  > novel user interface.  > novel user interface.
330  >  
331    We have added a lot of discussion there.
332    
333  > Section 5.1 - this review should continue beyond 1994!  > Section 5.1 - this review should continue beyond 1994!
334    
335    Done.
336    
337  > Section 5.4 - I think you are missing a trick here. The Semantic Web is  > Section 5.4 - I think you are missing a trick here. The Semantic Web is
338  > about machine interpretable information, rather than machine opaque  > about machine interpretable information, rather than machine opaque
339  > information collected in files. This is EXACTLY what you are doing. As  > information collected in files. This is EXACTLY what you are doing. As
340  > well as commenting on the coincidence of RDF adoption, explore the greater  > well as commenting on the coincidence of RDF adoption, explore the greater
341  > similarity. For example, does the existence of schemas and ontologies  > similarity. For example, does the existence of schemas and ontologies
342  > provide some slot-based structuring for your items?  > provide some slot-based structuring for your items?
343  >  
344  >  We have added some mention of this to both the RDF, Semantic Web
345    section and the FenPDF section.
346    
347    

Legend:
Removed from v.1.2  
changed lines
  Added in v.1.3

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