[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 15:19:25

Modified files:
        FutureVision   : referee-reply.txt 

Log message:
        Replies

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

Patches:
Index: manuscripts/FutureVision/referee-reply.txt
diff -u manuscripts/FutureVision/referee-reply.txt:1.1 
manuscripts/FutureVision/referee-reply.txt:1.2
--- manuscripts/FutureVision/referee-reply.txt:1.1      Thu Nov 13 15:04:12 2003
+++ manuscripts/FutureVision/referee-reply.txt  Thu Nov 13 15:19:25 2003
@@ -1,154 +1,215 @@
 (Our answer to how we addressed the referees' comments)
 
-REVIEW 1
-
-Overall, the paper makes some interesting points. I don\'t think there\'s
-a whole lot new here, but the work fits the theme of the issue.
-
-I thought the paper read poorly in places. It\'s problematic to say that
-you have come across an interface concerned with \"things people care
-about\" and not files or documents. I would wager most people in fact do
-map files to \"cared about things\" fairly closely. The *constant use of
-bold* makes the paper look more like a *marketing brochure* than an
-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.
-
-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,
-not a fact. Indeed, it seems most structure visualizations have been shown
-to be pretty unhelpful after a certain threshold of information volume has
-been reached. The examples in the paper show a few items linked in a few
-ways. What happens if one has, say, 500,000 items. I have about that many
-files on my laptop. Is _any_ visulaization worthwhile at that scale? Is
-any computationally feasible?
-
-The notion of separate views has been around since the early HM days: see
-the Texas A&M work of the late 80\'s and early 90\'s, in which links were
-mae to views and not documents. Would be a good reference in this paper.
-
-I\'m not sure I believe that you are really able to contextualize things
-very well here. There does not seem to be a first-class system object
-called view that is obviously manipulatable at the interface. Without
-this, how can one, for example, version a particular view on a particular
-item space? Also, the RDF assertions seem to be philosophically
-diametrically opposed to recontextualization. If I have two academic
-paapers, how will I express that, under one set of assertions, the papers
-support one another, while under another, they contradict one another?
-Won\'t I end up just building two relations that need to be manually
-disambiguated at \"run-time\"? This functionality is what I understand by
-recontextualization, and I\'m not clear how that gets expressed in your
-system.
-
-In sum, the papers seems to have some interesting ideas floating around.
-Currently, the paper reads poorly, and the ideas that are there aren\'t
-well expressed. I think that assertion and conjecture need to be clearly
-marked as such (it\'s ok to have that - it just needs to be made clear
-where it is) and your original contribution needs more explanation. The
-article in its current form is still rather short and could easily
-accomodate more (\"real-world\") examples. The references you give are
-applicable, but aren\'t sufficient. Also, FOHM is probably a controversial
-choice as a representative of the OHS perspective. The work on Callimachus
-(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.
-
-As an aside, I gave this paper to one of my grad students to read, who had
-some of the same scalability concerns, more from a usability perspective
-than a computational one.
-
-REVIEW 2
-
- This paper describes some initial attempts towards building hypertext
-systems that are motivated by the need to make the \'item of interest\' an
-explicit focus of the computer\'s internal and interaction paradigm. This
-motivation (originally articulated by Nelson) has been implemented in
-several forms by the authors over a number of years.
-
-Although the paper descibes an attempt to implement Nelson\'s vision, one
-of the problems is that the authors have chosen to speak with Nelson\'s
-voice, describing his ideas using his language. As researchers with their
-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.
-
-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.
-
-The presentation of the paper though is currently too bitty - too many
-unelaborated claims interspersed with irrelevant technical details.
-
-
-Specific Comments--
-Abstract: if we build systems structured around things we care about,
-would that necessarily help us organise our lives?
-
-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\'?
-
-Section 2, sentence 1: delete comma after \"medium\"
-Section 2, para 5: planning should not be capitalised
-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?
-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.
-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
-useful visualisation!
-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
-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.
-
-
-Section 3.1: an illustration of the zzStructure might be useful,
-especially if it could be compared with an RDF structure in 3.2
-Section 3.2: zzStructure is simpler to browse locally because it has
-higher-level (user-centred) semantics.
-Section 3.2: How does the many-many relationship change the data
-structure?
-
-Section 4: comments on the internal architecture (relatively monolithic -
-is this an oxymoron?) seem out of place, and are also not well explained.
-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.
-Section 4.2.1: RDF visualisation is something which is not uncommon in the
-semantic web. Please indicate how your approach differs from RDFViz
-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.
-Figure 5: Although I think I understand what the figure should be showing
-me, I can\'t see it in the screenshots themselves.
-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?
-Section 4.3: I\'m not sure what this description of the user interface
-library provides the rest of trhe paper.
-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.
-
-Section 5.1 - this review should continue beyond 1994!
-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?
-
-
+> REVIEW 1
+> 
+> Overall, the paper makes some interesting points. I don\'t think there\'s
+> a whole lot new here, but the work fits the theme of the issue.
+> 
+> I thought the paper read poorly in places. It\'s problematic to say that
+> you have come across an interface concerned with \"things people care
+> about\" and not files or documents. I would wager most people in fact do
+> map files to \"cared about things\" fairly closely. 
+
+We have clarified our explanation of this - our original expression
+was not good.
+
+Yes, people use files and directories so that they do map to items;
+however, the converse is not always true. It is not possible
+to map *all* items you care about to files or directories, for example
+for meetings, people, places, ...
+
+> The *constant use of
+> bold* makes the paper look more like a *marketing brochure* than an
+> 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. 
+
+> 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,
+> not a fact. Indeed, it seems most structure visualizations have been shown
+> to be pretty unhelpful after a certain threshold of information volume has
+> been reached. The examples in the paper show a few items linked in a few
+> ways. What happens if one has, say, 500,000 items. I have about that many
+> files on my laptop. Is _any_ visulaization worthwhile at that scale? Is
+> any computationally feasible?
+
+This is also something we have tried to make clear in the manuscript.
+
+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
+probably be categorized to meetings about paper A, meetings about research
+grant B, ...
+
+Then, Carli would only be connected directly to these categories,
+allowing a reasonable local visualization.
+
+With a suitable back-end code, viewing 10 or 100 or even 1000 nodes
+from a 500,000 node network is still very efficient.
+
+> The notion of separate views has been around since the early HM days: see
+> the Texas A&M work of the late 80\'s and early 90\'s, in which links were
+> mae to views and not documents. Would be a good reference in this paper.
+> 
+> I\'m not sure I believe that you are really able to contextualize things
+> very well here. There does not seem to be a first-class system object
+> called view that is obviously manipulatable at the interface. Without
+> this, how can one, for example, version a particular view on a particular
+> item space? 
+
+This seems to indicate that we have not made it clear what we mean by a view.
+For us, a view is simply a mapping from a RDF graph to a screen display.
+It is not an object that is versioned or that anything can be connected
+to; the connections are in the underlying *structure*.
+
+We have tried to clarify this with examples and more discussion.
+
+> Also, the RDF assertions seem to be philosophically
+> diametrically opposed to recontextualization. If I have two academic
+> paapers, how will I express that, under one set of assertions, the papers
+> support one another, while under another, they contradict one another?
+> Won\'t I end up just building two relations that need to be manually
+> disambiguated at \"run-time\"? This functionality is what I understand by
+> recontextualization, and I\'m not clear how that gets expressed in your
+> system.
+
+We have added some discussion of this.
+
+For example, in FenPDF, one would make a new canvas, quote there
+from both papers and, with words, *describe* the support and contradiction.
+
+If talking about RDF structures in general, then the answer would be
+reification, but that is not really related to our work.
+
+> In sum, the papers seems to have some interesting ideas floating around.
+> Currently, the paper reads poorly, and the ideas that are there aren\'t
+> well expressed. I think that assertion and conjecture need to be clearly
+> marked as such (it\'s ok to have that - it just needs to be made clear
+> where it is) and your original contribution needs more explanation. 
+
+We have tried to do this.
+
+> The
+> article in its current form is still rather short and could easily
+> accomodate more (\"real-world\") examples. 
+
+We have added some more discussion about examples.
+
+> The references you give are
+> applicable, but aren\'t sufficient. 
+
+Several references have been added.
+
+> Also, FOHM is probably a controversial
+> choice as a representative of the OHS perspective. The work on Callimachus
+> (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.
+
+We have added this reference.
+
+> As an aside, I gave this paper to one of my grad students to read, who had
+> some of the same scalability concerns, more from a usability perspective
+> than a computational one.
+
+The discussion above, about these concerns, applies here, too.
+
+> REVIEW 2
+> 
+>  This paper describes some initial attempts towards building hypertext
+> systems that are motivated by the need to make the \'item of interest\' an
+> explicit focus of the computer\'s internal and interaction paradigm. This
+> motivation (originally articulated by Nelson) has been implemented in
+> several forms by the authors over a number of years.
+> 
+> Although the paper descibes an attempt to implement Nelson\'s vision, one
+> of the problems is that the authors have chosen to speak with Nelson\'s
+> voice, describing his ideas using his language. As researchers with their
+> 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.
+> 
+> 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.
+> 
+> The presentation of the paper though is currently too bitty - too many
+> unelaborated claims interspersed with irrelevant technical details.
+> 
+> 
+> Specific Comments--
+> Abstract: if we build systems structured around things we care about,
+> would that necessarily help us organise our lives?
+> 
+> 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\'?
+> 
+> Section 2, sentence 1: delete comma after \"medium\"
+> Section 2, para 5: planning should not be capitalised
+> 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?
+> 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.
+> 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
+> useful visualisation!
+> 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
+> 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.
+> 
+> 
+> Section 3.1: an illustration of the zzStructure might be useful,
+> especially if it could be compared with an RDF structure in 3.2
+> Section 3.2: zzStructure is simpler to browse locally because it has
+> higher-level (user-centred) semantics.
+> Section 3.2: How does the many-many relationship change the data
+> structure?
+> 
+> Section 4: comments on the internal architecture (relatively monolithic -
+> is this an oxymoron?) seem out of place, and are also not well explained.
+> 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.
+> Section 4.2.1: RDF visualisation is something which is not uncommon in the
+> semantic web. Please indicate how your approach differs from RDFViz
+> 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.
+> Figure 5: Although I think I understand what the figure should be showing
+> me, I can\'t see it in the screenshots themselves.
+> 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?
+> Section 4.3: I\'m not sure what this description of the user interface
+> library provides the rest of trhe paper.
+> 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.
+> 
+> Section 5.1 - this review should continue beyond 1994!
+> 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?
+> 
+>