- From: Charles Petrie <petrie@stanford.edu>
- Date: Sun, 27 Jan 2008 15:49:14 -0800
- To: Ulrich.Kuester@uni-jena.de
- CC: member-xg-swsc@w3.org, public-xg-swsc@w3.org
Hi Uli, I like suggestion A) and we'll see if it is feasible to implement for the next workshop. You're an organizer, so let's see. I agree with B) in principle, but I don't know that everyone should follow your format. For a general methodology, what I would like, and what should go into a CFP to implement A), would be the criteria: 1) A common machine readable format such as XML, KIF, SAWSDL, or something for which there exists available free parsers and/or well-published specification. 2) The content should be useful for solving the problem(s). An example would be an ontology for time that enables different problems to be solved with a minimal change. It might be a way of annotating the WSDL so that a problem solver can work with it more automatically. 3) The content should illustrate some principles of the approach that others can evaluate the utility of it, perhaps deciding to adapt and re-use it. 4) The content should understandable without having to install a large system, but it is desirable that there be a pointer to a working system that will consume the content. The more information about the working context of the system, better. OK, that should start a discussion. Best, Charles -- http://www-cdr.stanford.edu/~petrie Date: Thu, 24 Jan 2008 18:11:17 +0100 From: =?ISO-8859-15?Q?Ulrich_K=FCster?= <Ulrich.Kuester@uni-jena.de> X-Enigmail-Version: 0.95.6 OpenPGP: id=4DC8D230 Received-SPF: none X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1JI5bn-0003uR-42 791639b478d03131b852bc7864602aaf X-Original-To: public-xg-swsc@w3.org Archived-At: <http://www.w3.org/mid/4798C6B5.9050909@uni-jena.de> Resent-From: public-xg-swsc@w3.org X-Mailing-List: <public-xg-swsc@w3.org> archive/latest/4 X-Loop: public-xg-swsc@w3.org Sender: public-xg-swsc-request@w3.org Resent-Sender: public-xg-swsc-request@w3.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, | Finally, EVERYONE: *please* post your individual solutions with | *re-usuable code/ontologies*. Please. This is terribly important. Charles has been repeatedly trying to make people document and share their solutions. Generally with moderate success so far. In my opinion however, one of the main goals of the Challenge is to improve the mutual understandings of each others technologies. For this task sharing solutions and providing technical documentation of solutions is absolutely crucial. Furthermore - as Tiziana has correctly pointed out - an evaluation made by group consensus is not fully objective. Currently, however, we have no better evaluation means than the group consensus at the workshops. This group consensus would become much more transparent and reliable, if solutions were documented in a way that independent people can later see and understand why the group came to a certain consensus. Without documented solutions (also at a technical level) this is impossible. If the certified solutions are not shared, the evaluation is not only subjective, but even worse intransparent and unreproducable. I therefore do believe, that we need to explicit our requirements with regard to sharing and documenting solutions and propose the following: A) Making people upload solutions For upcoming workshops we should put the certification results on the web only conditionally and remove them, if participants fail to document their solution and share the declarative parts of the solution by a certain deadline (e.g. one month after a workshop). For people who cannot share their solution due to IP rights, we could mark the certification results as only partially reproducable due to the unability to share the solution code. In this aspect it might be interesting to read the experimental repeatability requirements of SIGMOD at http://www.sigmod08.org/sigmod_research.shtml B) Unifying how solutions are documented If I look at the DERI solution page and compare it with mine, the way how solutions have been described is very different. While DERI documented their overall work on a more abstract level, I tried to document on a more technical level. Both has clearly its value and its advantages and disadvantages. I think however, that solution documentations are more useful, if they conform to certain guidelines about what needs to be provided and where certain informations can be found. Two examples: The DERI page does not provide pointers to the developed service or goal descriptions. The Jena page does not provide an overview of the general setting of the work and general information about the employed technology. Both deficiencies would have been avoided if requirements on solution documentation would have been specified. I would like to hear your opinions on both aspect (A and B) and put that on the standardization agenda. Finally it was brought to my attentions that the charter of the group states: "This group primarily conducts its work on the public mailing list public-xg-swsc@w3.org (archive)". Clearly this is not what we have been doing so far. I therefore propose a vote about moving the discussion to the public mailing list from now on. I'm +1. Best regards, Uli -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: GnuPT 2.9.2 iD8DBQFHmMax8VxeCU3I0jARAlkIAJ955rIxyA731XVjSjdulLmErZDsEgCgg36D Rya9OOO0K5bbZ0KFKj2IzaM= =3Pmi -----END PGP SIGNATURE-----
Received on Monday, 28 January 2008 05:35:19 UTC