Referee 1 ******************************************* E: Referee Comments (For Author and Editor) ------------------------------ This paper describes a recommendation service for scientific systems. Scientists can now invoke this system to find out the resources and problem size that can give them the results they desire on the grid. Creating and maintaining such a database is a useful effort. However, I am not convinced that the grid community right now is mature enough to use such a database. Typically, most users feel that their problem formulation is unique; in many research cases, that notion is true. It's not clear whether the run-time details of other users, even if they ran the same problem, matter to current users. Besides, the entires in the MyPYTHIA database transfer to other users only if the current and previous users happen to have access to the same set of resources. The paper is weak on some of the interesting technical details. For example, Section 3.3, which I would have thought would have been the meat of the paper, reads like a survey. How are the various algorithms implemented in MyPYTHIA? Do users select from them? Are hybrids of the algorithms used? All of them? Some of them? Are there benefits to using one over the other? I expected this section to convince me that a MyPYTHIA databases can help users share their run-time experiences. In contrast, Sections 3.1 and 3.5 don't deserve the detailed treatment given to them. Most readers understand retrieval systems and user interface components. A word to the wise is sufficient. A concern I have about this work is the accumulation of data about scientific runs. Do we have any justification that users or even domain experts will enter copious amounts of data about their runs in some database or the other? In summary, I think the concept is good, although perhaps a bit ahead of its time. I'd like to see more technical detail about how decision systems are invoked and recommendations made, and less detail about database organisation and user interfaces. F: Presentation Changes The writing in the paper is pretty good. I'd suggest a few small changes. * Some parts of the paper read very much like they were written by different authors. For example, "a priori" is spelt or typeset differently in three places. Ditto for "PROGOL". Also, the conventions for quoted text are different in different places. * Some terms are used without definition. For example, see Section 2. We have no definition for U and R. * Remove spelling errors. For example, "quarantee", "maintaing". * Remove grammatical errors. For example, "outside of" is bad usage unless "outside" is used as a noun (in which case it is preceded by "the"). Remove unbound or ambiguous referents such as "this" not preceded by a noun. * Citations are not first-class words. In other words, don't say "See [1] for Einstein's Theory of Relativity", or "Einstein presents a theory in [1]". Instead, to say "Einstein presents the Theory of Relativity [1]". Referee 2 ******************************************* Referee Recommendation: Accepted provided changes suggested are made Overview: This paper presented the MyPYTHIA knowledge based recommendation system, aimed at maintaining information about grid-oriented large-scale applications. Applications are controlled via a simple and comprehensive web portal based on the phpMyAdmin project. The portal gives access to MySQL databases through the use of PHP scripts. After presenting the motivations for a recommendation and knowledge-based systems, the paper describes the structure of the Database that maintains applications information. It then presents a case study and some typical applications. Organization: The overall paper is well presented and easy to read. A "discussion" subsection in the final section is missing. Technical Content: The overall description of the transition to a fully web-enabled application (from PYTHIA and PYTHIA II) and the use of an XML-like structure for importing data seem like the right direction. However, a discussion on the advantages and drawbacks of using PHP and MySQL as opposed to other Programming Languages/Database system pairs (C, Perl, Python.../PostgreSQL, Oracle...) would be very informative and interesting given that PHP and MySQL are not typically used when it comes to processing speed and handling very large relational databases. The description of the MyPYTHIA application is very detailed and precise however, the overall goals and what is actually achieved is not clear - the section might be broken down into a "higher-level goals to achieve" and "technical description" subsections. Innovation: Enabling such a recommendation system on the web is the real contribution of this work. The definition of the fields and tables of the database is valuable information that can help scientific application developers to better structure the requirements of their work. Ease of use and the actual usage by scientists is the point that MyPYTHIA now raises. References: PHP, MySQL, Apache and phpMyAdmin are mentioned in a footnote but not present in the references section. Recommendations & Presentation changes: What seems to be missing is a scenario diagram showing simply and clearly what a user could request and what he/she would get by describing at a high-level the different steps taken to obtain a result. Referee 3 ******************************************* E: Referee Comments (For Author and Editor) ------------------------------ This paper does not speak to the pratical experiences in building the MyPYTHIA web portal or grid computing. It spends far too much of its time describing in detail the background science of the underlying technologies that the portal is supposed to be abstracting. Little mention of Grid technologies other than light reference to some data projects. The authenticaion is only mentioned when it is mentioned that a user needs to get a username and password. This paper does not provide what the journal asked for, so it does not appear to be a Grid project. There is no dicusssion of what resources are used or where the computational work is performed. F: Presentation Changes see below. MORE DETAILED COMMENTS FROM READERS: A.Presentation grade=1 +some nice images of the UI. +language and grammar are good. (only minor errors there) -no examples of the input and the output, I have no grasp of how this portal works at all. It talks in great detail about the science behind the cases covered by the portal, but there's no clear example of user input and output received through this portal. For example, where and on what are the pattern extraction algorithms being run? Are they computationally intensive? Do you execute them on the grid, or are they just run on the webserver? It seems like the separate modules of this system are described well, but no effort was made into explaining how they integrate. -no architechure layout. I think this paper would benefit greatly from an architechture diagram. B.Competence grade=2/5 +portal seems competently put together +science behind the portal seems competent +many pieces of the technology are explained in great detail -the design of the portal is not really covered, and the bits that are covered are scattered throughout the paper. ** Contribution (relevant to special issue) grade=1/5 +seems like a good recommendation system for data +nice to have this in a portal -grid??????? there appears to be no grid anything in this system -it looks like a big database with web page to access it. -no discussion of the practical experieces of setting this. -no discussion of issues involved, barriers overcome, problems still left. -I think this paper would be fine if it were not submitted to this particular journal. ** Originality grade=2/5 -there are web pages which do database lookups. this is not original in terms of the pratical experience of building new technology at all. using php to do database queries just isn't that original. +however, I don't know of any portals which do exactly the science being done here. the software system, PYTHIA, is the original contribution. ** Strengths +sounds like it runs...although this is not stated anywhere in the paper. +the separate components of MyPYTHIA are explained well. +the underlying science apart from the portal is thoroughly described. +good descriptions of the representations required by MyPYTHIA for generating inference data (could really really use a simple example though!) +it has very lengthy discussions on several case studies +it shows in great detail the science behind the MyPYTHIA web system. +has nice snapshots of GUI.