[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gzz-commits] manuscripts/FutureVision referee-reply.txt
From: |
Tuomas J. Lukka |
Subject: |
[Gzz-commits] manuscripts/FutureVision referee-reply.txt |
Date: |
Thu, 13 Nov 2003 16:30:10 -0500 |
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.
+
+