Re: How to proceed wrt publishing solutions?

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