[Gzz-commits] manuscripts/FutureVision referee-reply.txt

[Tuomas J. Lukka]

CVSROOT:        /cvsroot/gzz
Module name:    manuscripts
Branch:         
Changes by:     Tuomas J. Lukka <address@hidden>        03/11/13 16:30:10

Modified files:
        FutureVision   : referee-reply.txt 

Log message:
        reply

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/manuscripts/FutureVision/referee-reply.txt.diff?tr1=1.2&tr2=1.3&r1=text&r2=text

Patches:
Index: manuscripts/FutureVision/referee-reply.txt
diff -u manuscripts/FutureVision/referee-reply.txt:1.2 
manuscripts/FutureVision/referee-reply.txt:1.3
--- manuscripts/FutureVision/referee-reply.txt:1.2      Thu Nov 13 15:19:25 2003
+++ manuscripts/FutureVision/referee-reply.txt  Thu Nov 13 16:30:08 2003
@@ -10,6 +10,10 @@
 > about\" and not files or documents. I would wager most people in fact do
 > map files to \"cared about things\" fairly closely. 
 
+Thank you; our original argument was indeed flawed. We have removed
+our original claims about files and directories in favor of discussion
+about how our work 
+
 We have clarified our explanation of this - our original expression
 was not good.
 
@@ -23,8 +27,9 @@
 > academic paper. I think the paper could be improved by recasting it in a
 > more academic tone and less like you are trying to sell something.
 
-The use of bold and writing scannable text is what the JoDi guidelines 
-themselves recommend, so we have kept them. 
+The use of bold and writing scannable text is what the JoDI guidelines 
+themselves recommend (refering to Nielsen's guidelines for
+writing for the Web), so we have kept them. 
 
 > I\'m familiar with Nelson\'s assertion that structure needs to be
 > visualized, but as far as I know, this is still very much an assertion,
@@ -40,7 +45,7 @@
 We only show the currently focused item and the items that are close
 to it in the network of items. The local degree of the item graph
 is not terribly high; if it is, it can be adjusted to a more reasonable
-structure. For example, if there are 1000 meetings with carli, they'd
+structure. For example, if there are 1000 meetings with Carli, they'd
 probably be categorized to meetings about paper A, meetings about research
 grant B, ...
 
@@ -108,6 +113,7 @@
 > (U. Patras) is probably better illustrative of the point it looks like you
 > were trying to make, since it\'s both earlier and more general.
 
+Thank you, we hadn't seen that article.
 We have added this reference.
 
 > As an aside, I gave this paper to one of my grad students to read, who had
@@ -130,86 +136,212 @@
 > own experience of zzStructure and latterly RDF, they should concentrate on
 > developing their own story about the work that they do instead of
 > recycling the (rather technophobic) Nelson account.
-> 
+
+As a matter of opinion, we don't consider Nelson technophobic but
+rather "bad-techno"-phobic..
+
+We have tried to smooth over some of the more controversial expressions,
+as related to denigrating files and directories, as mentioned
+in the reply to REVIEW 1.
+
 > In particular, I believe that there is the basis of some really
 > interesting Semantic Web work here, where item-based editing and display
 > is just one application of in terms of application-neutral, semantically
 > modelled data.
-> 
+
+We have added a mention of this to the FenPDF section.
+
 > The presentation of the paper though is currently too bitty - too many
 > unelaborated claims interspersed with irrelevant technical details.
-> 
-> 
+
+We have tried to address this as best we can.
+
 > Specific Comments--
 > Abstract: if we build systems structured around things we care about,
 > would that necessarily help us organise our lives?
-> 
+
+Changed to explicitly mention that this is conjecture (as per REVIEW 1
+as well).
+
 > Introduction: instead of being centred around files/directories...center
 > around the things we care about. But surely we will always need to develop
 > abstractions for aggregation? Will they not be similar to directories?
 > Even in the description of applitudes there are still email bodies (which
 > seem remarkably free of items). Are these not \'files\'?
-> 
+
+This point is the same we discussed in relation to REVIEW 1, and possibly
+was what made us seem technophobic. We have made clearer what we meant.
+
 > Section 2, sentence 1: delete comma after \"medium\"
 > Section 2, para 5: planning should not be capitalised
+
+Done
+
 > Section 2, para 6: \"we propose to build\" - why not just make items the
 > user interface paradigm? Why not still have files and directories
 > underneath?
+
+We have added a note: this is possible, of course, but we have chosen
+not to do so, because the files and directories underneath are not stable;
+we want our system to store information reliably, and integration of such
+reliability with a filesystem is quite problematic.
+
 > Figure 1: the diagram shows 1 item (person) under focus. However, the suer
 > may know hundreds of people - dozens with some form of relationship to
 > Carli. Some of the earliest hypertext systems attempted to make use of
 > similar maps - and failed. Explain why your system won\'t have the same
 > failings.
+
+We have tried to explain this in detail in section 2. The views
+are not static maps - they are 
+dynamic and the user can interactively scroll and adjust various parameters.
+We also discuss various reasons why such a high number of connections
+should not occur in realistic uses of this system.
+
 > Figure 2a: Where are the items *inside* the email? Is the email just a
-> file of content? I receive 100 emails a day - convince me that this is a
+> file of content? 
+
+The email in the example is just text, like email today is. We do not
+propose to replace email and, e.g., academic articles by several items
+because these are data that come to our system from the outside.
+It *is*, however, possible to *transclude* text from an email
+into a new item, and have that item remain connected to the email
+through the transclusion.
+
+> I receive 100 emails a day - convince me that this is a
 > useful visualisation!
+
+This is related to the discussion about item overload we have addressed
+above.
+
 > Final 2 paragraphs of section 2 - you claim that paper isn\'t useful to
 > help us organise our thoughts, but that a hyperstructure will be. Your
 > claim seems to rest on the idea that the more interconnections there are,
-> the more organised everything will be. Is this likely? Convince me that
+> the more organised everything will be. 
+
+No, not "the more, the more", but a reasonable amount of interconnections.
+
+Paper is useful, but paper notes are not easily connected to other
+paper notes.
+
+> Is this likely? Convince me that
 > you have thought this through rather than reciting Nelson\'s view. Have a
 > look at the network diagrams from the early Intermedia papers on the
 > Victorian web.
-> 
-> 
+
+A fundamental difference between the Intermedia views and our work 
+is that in the maps we saw, for example, in Utting's article, 
+*icons* are used to represent the different nodes around the 
+given node.
+
+This is something that we do differently: for example, in FenPDF
+an article is never represented by something other than itself.
+There is no icon, no filename, nothing like that to add to the cognitive
+load of the user. Rather, it is always the picture of the article itself,
+or a fragment. The unique backgrounds make this an especially 
+useful alternative, since for familiar articles, you can recognize
+them at a glance.
+
+All this is made possible by the increased graphics processing power
+offered by modern OpenGL accelerators.
+
+The difference is to us so obvious that we forgot to mention
+it explicitly in the article, but a very important one, we feel.
+
+We have discussed this in the new section 5.4 (we noticed that
+we had a numbering error in the orig. manuscript so the section
+numbers haven't changed ;).
+
 > Section 3.1: an illustration of the zzStructure might be useful,
 > especially if it could be compared with an RDF structure in 3.2
+
+Added.
+
 > Section 3.2: zzStructure is simpler to browse locally because it has
 > higher-level (user-centred) semantics.
+
+A good point, we have added this and acknowledged the referee.
+
 > Section 3.2: How does the many-many relationship change the data
 > structure?
-> 
+
+We have added discussion of this.
+
 > Section 4: comments on the internal architecture (relatively monolithic -
 > is this an oxymoron?) seem out of place, and are also not well explained.
+
+The comment is removed, it was explaining a shortcoming
+of our current prototype, not the vision.
+
 > Section 4.1: Nelson used the word intertwingled to describe a complex
 > semantic interconnection. Please don\'t use it just to mean
 > \'interconnected\' or similar.
+
+Fixed.
+
 > Section 4.2.1: RDF visualisation is something which is not uncommon in the
 > semantic web. Please indicate how your approach differs from RDFViz
+
+Added discussion in section 5.4. Basically, RDFViz uses a plane
+embedding of the graph, we use a local subgraph.
+
 > Figure 4: Since this is the principle illustration of the concept of
 > buoys, this diagram should be clearer. It currently is a mass of little
 > thin lines.
+
+This is a figure from 
+that illustrates where the concept originates in the graphical
+language of drawing technical diagrams.  It is an authentic
+figure from NASA and changing it would make, to us, no sense.
+The full version of the figure (accessible by clicking the
+shrunken version in the image) is clearer than the reduced one.
+
 > Figure 5: Although I think I understand what the figure should be showing
 > me, I can\'t see it in the screenshots themselves.
+
+We have tried to make the graphics a little clearer, especially
+in the full version of the image.
+
+
 > End of section 4.2: the example of a map with a buoy for every person who
 > lives there kind of invites a very probing question - can you handle 1
 > million buoys? Can the user? Is this a fundamental problem with items -
 > just too many of them to handle?
+
+This is, again, the scalability issues we have addressed above.
+Showing all persons on a map would make no sense as a visualization;
+showing the persons the user knows is a much smaller set and makes sense.
+
+The user's space wouldn't contain the phonebook and even if it did,
+showing the phonebook in that visualization wouldn't usually make sense.
+
 > Section 4.3: I\'m not sure what this description of the user interface
 > library provides the rest of trhe paper.
+
+We have considerably revised this section to make its relationship
+clearer.
+
 > Section 4.4: This seems to be potentially the most exciting part of the
 > paper but I think that too little has been made of it. Develop a scenario
 > of the use of FenPDF for understanding or organising academic literature
 > (tie it back to the major objectives of the apper outlined in the
 > introduction). At the moment it is simply a too-brief demonstration of a
 > novel user interface.
-> 
+
+We have added a lot of discussion there.
+
 > Section 5.1 - this review should continue beyond 1994!
+
+Done.
+
 > Section 5.4 - I think you are missing a trick here. The Semantic Web is
 > about machine interpretable information, rather than machine opaque
 > information collected in files. This is EXACTLY what you are doing. As
 > well as commenting on the coincidence of RDF adoption, explore the greater
 > similarity. For example, does the existence of schemas and ontologies
 > provide some slot-based structuring for your items?
-> 
-> 
+
+We have added some mention of this to both the RDF, Semantic Web
+section and the FenPDF section.
+
+