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 |
|
|
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, |
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 |
|
|
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 |
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 |
|
|