/[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.1 by benja, Thu Nov 13 20:04:12 2003 UTC revision 1.2 by tjl, Thu Nov 13 20:19:25 2003 UTC
# Line 1  Line 1 
1  (Our answer to how we addressed the referees' comments)  (Our answer to how we addressed the referees' comments)
2    
3  REVIEW 1  > REVIEW 1
4    >
5  Overall, the paper makes some interesting points. I don\'t think there\'s  > Overall, the paper makes some interesting points. I don\'t think there\'s
6  a whole lot new here, but the work fits the theme of the issue.  > a whole lot new here, but the work fits the theme of the issue.
7    >
8  I thought the paper read poorly in places. It\'s problematic to say that  > I thought the paper read poorly in places. It\'s problematic to say that
9  you have come across an interface concerned with \"things people care  > you have come across an interface concerned with \"things people care
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. The *constant use of  > map files to \"cared about things\" fairly closely.
12  bold* makes the paper look more like a *marketing brochure* than an  
13  academic paper. I think the paper could be improved by recasting it in a  We have clarified our explanation of this - our original expression
14  more academic tone and less like you are trying to sell something.  was not good.
15    
16  I\'m familiar with Nelson\'s assertion that structure needs to be  Yes, people use files and directories so that they do map to items;
17  visualized, but as far as I know, this is still very much an assertion,  however, the converse is not always true. It is not possible
18  not a fact. Indeed, it seems most structure visualizations have been shown  to map *all* items you care about to files or directories, for example
19  to be pretty unhelpful after a certain threshold of information volume has  for meetings, people, places, ...
20  been reached. The examples in the paper show a few items linked in a few  
21  ways. What happens if one has, say, 500,000 items. I have about that many  > The *constant use of
22  files on my laptop. Is _any_ visulaization worthwhile at that scale? Is  > bold* makes the paper look more like a *marketing brochure* than an
23  any computationally feasible?  > academic paper. I think the paper could be improved by recasting it in a
24    > more academic tone and less like you are trying to sell something.
25  The notion of separate views has been around since the early HM days: see  
26  the Texas A&M work of the late 80\'s and early 90\'s, in which links were  The use of bold and writing scannable text is what the JoDi guidelines
27  mae to views and not documents. Would be a good reference in this paper.  themselves recommend, so we have kept them.
28    
29  I\'m not sure I believe that you are really able to contextualize things  > I\'m familiar with Nelson\'s assertion that structure needs to be
30  very well here. There does not seem to be a first-class system object  > visualized, but as far as I know, this is still very much an assertion,
31  called view that is obviously manipulatable at the interface. Without  > not a fact. Indeed, it seems most structure visualizations have been shown
32  this, how can one, for example, version a particular view on a particular  > to be pretty unhelpful after a certain threshold of information volume has
33  item space? Also, the RDF assertions seem to be philosophically  > been reached. The examples in the paper show a few items linked in a few
34  diametrically opposed to recontextualization. If I have two academic  > ways. What happens if one has, say, 500,000 items. I have about that many
35  paapers, how will I express that, under one set of assertions, the papers  > files on my laptop. Is _any_ visulaization worthwhile at that scale? Is
36  support one another, while under another, they contradict one another?  > any computationally feasible?
37  Won\'t I end up just building two relations that need to be manually  
38  disambiguated at \"run-time\"? This functionality is what I understand by  This is also something we have tried to make clear in the manuscript.
39  recontextualization, and I\'m not clear how that gets expressed in your  
40  system.  We only show the currently focused item and the items that are close
41    to it in the network of items. The local degree of the item graph
42  In sum, the papers seems to have some interesting ideas floating around.  is not terribly high; if it is, it can be adjusted to a more reasonable
43  Currently, the paper reads poorly, and the ideas that are there aren\'t  structure. For example, if there are 1000 meetings with carli, they'd
44  well expressed. I think that assertion and conjecture need to be clearly  probably be categorized to meetings about paper A, meetings about research
45  marked as such (it\'s ok to have that - it just needs to be made clear  grant B, ...
46  where it is) and your original contribution needs more explanation. The  
47  article in its current form is still rather short and could easily  Then, Carli would only be connected directly to these categories,
48  accomodate more (\"real-world\") examples. The references you give are  allowing a reasonable local visualization.
49  applicable, but aren\'t sufficient. Also, FOHM is probably a controversial  
50  choice as a representative of the OHS perspective. The work on Callimachus  With a suitable back-end code, viewing 10 or 100 or even 1000 nodes
51  (U. Patras) is probably better illustrative of the point it looks like you  from a 500,000 node network is still very efficient.
52  were trying to make, since it\'s both earlier and more general.  
53    > The notion of separate views has been around since the early HM days: see
54  As an aside, I gave this paper to one of my grad students to read, who had  > the Texas A&M work of the late 80\'s and early 90\'s, in which links were
55  some of the same scalability concerns, more from a usability perspective  > mae to views and not documents. Would be a good reference in this paper.
56  than a computational one.  >
57    > I\'m not sure I believe that you are really able to contextualize things
58  REVIEW 2  > very well here. There does not seem to be a first-class system object
59    > called view that is obviously manipulatable at the interface. Without
60   This paper describes some initial attempts towards building hypertext  > this, how can one, for example, version a particular view on a particular
61  systems that are motivated by the need to make the \'item of interest\' an  > item space?
62  explicit focus of the computer\'s internal and interaction paradigm. This  
63  motivation (originally articulated by Nelson) has been implemented in  This seems to indicate that we have not made it clear what we mean by a view.
64  several forms by the authors over a number of years.  For us, a view is simply a mapping from a RDF graph to a screen display.
65    It is not an object that is versioned or that anything can be connected
66  Although the paper descibes an attempt to implement Nelson\'s vision, one  to; the connections are in the underlying *structure*.
67  of the problems is that the authors have chosen to speak with Nelson\'s  
68  voice, describing his ideas using his language. As researchers with their  We have tried to clarify this with examples and more discussion.
69  own experience of zzStructure and latterly RDF, they should concentrate on  
70  developing their own story about the work that they do instead of  > Also, the RDF assertions seem to be philosophically
71  recycling the (rather technophobic) Nelson account.  > diametrically opposed to recontextualization. If I have two academic
72    > paapers, how will I express that, under one set of assertions, the papers
73  In particular, I believe that there is the basis of some really  > support one another, while under another, they contradict one another?
74  interesting Semantic Web work here, where item-based editing and display  > Won\'t I end up just building two relations that need to be manually
75  is just one application of in terms of application-neutral, semantically  > disambiguated at \"run-time\"? This functionality is what I understand by
76  modelled data.  > recontextualization, and I\'m not clear how that gets expressed in your
77    > system.
78  The presentation of the paper though is currently too bitty - too many  
79  unelaborated claims interspersed with irrelevant technical details.  We have added some discussion of this.
80    
81    For example, in FenPDF, one would make a new canvas, quote there
82  Specific Comments--  from both papers and, with words, *describe* the support and contradiction.
83  Abstract: if we build systems structured around things we care about,  
84  would that necessarily help us organise our lives?  If talking about RDF structures in general, then the answer would be
85    reification, but that is not really related to our work.
86  Introduction: instead of being centred around files/directories...center  
87  around the things we care about. But surely we will always need to develop  > In sum, the papers seems to have some interesting ideas floating around.
88  abstractions for aggregation? Will they not be similar to directories?  > Currently, the paper reads poorly, and the ideas that are there aren\'t
89  Even in the description of applitudes there are still email bodies (which  > well expressed. I think that assertion and conjecture need to be clearly
90  seem remarkably free of items). Are these not \'files\'?  > marked as such (it\'s ok to have that - it just needs to be made clear
91    > where it is) and your original contribution needs more explanation.
92  Section 2, sentence 1: delete comma after \"medium\"  
93  Section 2, para 5: planning should not be capitalised  We have tried to do this.
94  Section 2, para 6: \"we propose to build\" - why not just make items the  
95  user interface paradigm? Why not still have files and directories  > The
96  underneath?  > article in its current form is still rather short and could easily
97  Figure 1: the diagram shows 1 item (person) under focus. However, the suer  > accomodate more (\"real-world\") examples.
98  may know hundreds of people - dozens with some form of relationship to  
99  Carli. Some of the earliest hypertext systems attempted to make use of  We have added some more discussion about examples.
100  similar maps - and failed. Explain why your system won\'t have the same  
101  failings.  > The references you give are
102  Figure 2a: Where are the items *inside* the email? Is the email just a  > applicable, but aren\'t sufficient.
103  file of content? I receive 100 emails a day - convince me that this is a  
104  useful visualisation!  Several references have been added.
105  Final 2 paragraphs of section 2 - you claim that paper isn\'t useful to  
106  help us organise our thoughts, but that a hyperstructure will be. Your  > Also, FOHM is probably a controversial
107  claim seems to rest on the idea that the more interconnections there are,  > choice as a representative of the OHS perspective. The work on Callimachus
108  the more organised everything will be. Is this likely? Convince me that  > (U. Patras) is probably better illustrative of the point it looks like you
109  you have thought this through rather than reciting Nelson\'s view. Have a  > were trying to make, since it\'s both earlier and more general.
110  look at the network diagrams from the early Intermedia papers on the  
111  Victorian web.  We have added this reference.
112    
113    > As an aside, I gave this paper to one of my grad students to read, who had
114  Section 3.1: an illustration of the zzStructure might be useful,  > some of the same scalability concerns, more from a usability perspective
115  especially if it could be compared with an RDF structure in 3.2  > than a computational one.
116  Section 3.2: zzStructure is simpler to browse locally because it has  
117  higher-level (user-centred) semantics.  The discussion above, about these concerns, applies here, too.
118  Section 3.2: How does the many-many relationship change the data  
119  structure?  > REVIEW 2
120    >
121  Section 4: comments on the internal architecture (relatively monolithic -  >  This paper describes some initial attempts towards building hypertext
122  is this an oxymoron?) seem out of place, and are also not well explained.  > systems that are motivated by the need to make the \'item of interest\' an
123  Section 4.1: Nelson used the word intertwingled to describe a complex  > explicit focus of the computer\'s internal and interaction paradigm. This
124  semantic interconnection. Please don\'t use it just to mean  > motivation (originally articulated by Nelson) has been implemented in
125  \'interconnected\' or similar.  > several forms by the authors over a number of years.
126  Section 4.2.1: RDF visualisation is something which is not uncommon in the  >
127  semantic web. Please indicate how your approach differs from RDFViz  > Although the paper descibes an attempt to implement Nelson\'s vision, one
128  Figure 4: Since this is the principle illustration of the concept of  > of the problems is that the authors have chosen to speak with Nelson\'s
129  buoys, this diagram should be clearer. It currently is a mass of little  > voice, describing his ideas using his language. As researchers with their
130  thin lines.  > own experience of zzStructure and latterly RDF, they should concentrate on
131  Figure 5: Although I think I understand what the figure should be showing  > developing their own story about the work that they do instead of
132  me, I can\'t see it in the screenshots themselves.  > recycling the (rather technophobic) Nelson account.
133  End of section 4.2: the example of a map with a buoy for every person who  >
134  lives there kind of invites a very probing question - can you handle 1  > In particular, I believe that there is the basis of some really
135  million buoys? Can the user? Is this a fundamental problem with items -  > interesting Semantic Web work here, where item-based editing and display
136  just too many of them to handle?  > is just one application of in terms of application-neutral, semantically
137  Section 4.3: I\'m not sure what this description of the user interface  > modelled data.
138  library provides the rest of trhe paper.  >
139  Section 4.4: This seems to be potentially the most exciting part of the  > The presentation of the paper though is currently too bitty - too many
140  paper but I think that too little has been made of it. Develop a scenario  > unelaborated claims interspersed with irrelevant technical details.
141  of the use of FenPDF for understanding or organising academic literature  >
142  (tie it back to the major objectives of the apper outlined in the  >
143  introduction). At the moment it is simply a too-brief demonstration of a  > Specific Comments--
144  novel user interface.  > Abstract: if we build systems structured around things we care about,
145    > would that necessarily help us organise our lives?
146  Section 5.1 - this review should continue beyond 1994!  >
147  Section 5.4 - I think you are missing a trick here. The Semantic Web is  > Introduction: instead of being centred around files/directories...center
148  about machine interpretable information, rather than machine opaque  > around the things we care about. But surely we will always need to develop
149  information collected in files. This is EXACTLY what you are doing. As  > abstractions for aggregation? Will they not be similar to directories?
150  well as commenting on the coincidence of RDF adoption, explore the greater  > Even in the description of applitudes there are still email bodies (which
151  similarity. For example, does the existence of schemas and ontologies  > seem remarkably free of items). Are these not \'files\'?
152  provide some slot-based structuring for your items?  >
153    > Section 2, sentence 1: delete comma after \"medium\"
154    > Section 2, para 5: planning should not be capitalised
155    > Section 2, para 6: \"we propose to build\" - why not just make items the
156    > user interface paradigm? Why not still have files and directories
157    > underneath?
158    > Figure 1: the diagram shows 1 item (person) under focus. However, the suer
159    > may know hundreds of people - dozens with some form of relationship to
160    > Carli. Some of the earliest hypertext systems attempted to make use of
161    > similar maps - and failed. Explain why your system won\'t have the same
162    > failings.
163    > Figure 2a: Where are the items *inside* the email? Is the email just a
164    > file of content? I receive 100 emails a day - convince me that this is a
165    > useful visualisation!
166    > Final 2 paragraphs of section 2 - you claim that paper isn\'t useful to
167    > help us organise our thoughts, but that a hyperstructure will be. Your
168    > claim seems to rest on the idea that the more interconnections there are,
169    > the more organised everything will be. Is this likely? Convince me that
170    > you have thought this through rather than reciting Nelson\'s view. Have a
171    > look at the network diagrams from the early Intermedia papers on the
172    > Victorian web.
173    >
174    >
175    > Section 3.1: an illustration of the zzStructure might be useful,
176    > especially if it could be compared with an RDF structure in 3.2
177    > Section 3.2: zzStructure is simpler to browse locally because it has
178    > higher-level (user-centred) semantics.
179    > Section 3.2: How does the many-many relationship change the data
180    > structure?
181    >
182    > Section 4: comments on the internal architecture (relatively monolithic -
183    > is this an oxymoron?) seem out of place, and are also not well explained.
184    > Section 4.1: Nelson used the word intertwingled to describe a complex
185    > semantic interconnection. Please don\'t use it just to mean
186    > \'interconnected\' or similar.
187    > Section 4.2.1: RDF visualisation is something which is not uncommon in the
188    > semantic web. Please indicate how your approach differs from RDFViz
189    > Figure 4: Since this is the principle illustration of the concept of
190    > buoys, this diagram should be clearer. It currently is a mass of little
191    > thin lines.
192    > Figure 5: Although I think I understand what the figure should be showing
193    > me, I can\'t see it in the screenshots themselves.
194    > End of section 4.2: the example of a map with a buoy for every person who
195    > lives there kind of invites a very probing question - can you handle 1
196    > million buoys? Can the user? Is this a fundamental problem with items -
197    > just too many of them to handle?
198    > Section 4.3: I\'m not sure what this description of the user interface
199    > library provides the rest of trhe paper.
200    > Section 4.4: This seems to be potentially the most exciting part of the
201    > paper but I think that too little has been made of it. Develop a scenario
202    > of the use of FenPDF for understanding or organising academic literature
203    > (tie it back to the major objectives of the apper outlined in the
204    > introduction). At the moment it is simply a too-brief demonstration of a
205    > novel user interface.
206    >
207    > Section 5.1 - this review should continue beyond 1994!
208    > Section 5.4 - I think you are missing a trick here. The Semantic Web is
209    > about machine interpretable information, rather than machine opaque
210    > information collected in files. This is EXACTLY what you are doing. As
211    > well as commenting on the coincidence of RDF adoption, explore the greater
212    > similarity. For example, does the existence of schemas and ontologies
213    > provide some slot-based structuring for your items?
214    >
215    >

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

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