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