Re: How to proceed wrt publishing solutions?

 > well-published specifications is a quite sloppy one. 

Hi Uli,
 I don't mind if it "sloppy" - they are all imprecise at some level.
But I do like your point that particular formats should be allowed.
However, I would say that shared formats are very preferable to
to formats used only by a single participant. At the very least,
something like a BNF should be available as well.

 > This addresses the issue of promoting reuse. That's a fair issue but I
 > would like to put more importance on promoting the general understanding
 > for the nature and approach of the solutions than the reuse of elements
 > of them.

These issues are related because you know you understand if you can
reuse, and not necessarially otherwise. But also, I would like a
result of this exercise to be something like common "best-of-breed"
semantics. Notice that 2) actually addresses a different point
though: that what is published actually helps to solve the problem.
Point 3) does exactly what you want above.

 > |  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.
 > 
 > I agree. I would add and stress that the content should enable the
 > reader to understand a particular solution on the technical level and
 > preferably get a solution running (after all running and implemented
 > solutions is what the challenge is about). I only get a real feeling for
 > an approach if I have used it to solve a concrete problem. As an
 > example, I do not only want to see the time ontologies of the other
 > approaches, I want to see how they actually described the services and
 > goals to get a feeling which problems have been expressed and solved how.

Yes, so, please do suggest an additional specification here. Notice
that this very similar to my point that understanding comes with
reuse. Perhaps just an additional comment is needed, expanding
upon the point that the more the better.

 > Maybe we need to come up with a scenario specific list of items 

I think this is not only too hard but also might constrict the
approach. Suppose, for instance, that someone is taking a completely
non-semantic approach and prgramming the solution in, say, PERL.
They would be publishing a lot of code and we would have a hard
time specififying ahead of time what they should publish. 

And we want to identify the most general methodology in this
incubator.  We might end up doing something like this in the future in
the SWS Challenge but someone else running a similar challenge in
the future following this methodology might not find such
specificity either feasible or useful.

Best, Charles
-- 
http://www-cdr.stanford.edu/~petrie

   Date: Mon, 28 Jan 2008 08:44:01 +0100
   From: =?ISO-8859-15?Q?Ulrich_K=FCster?= <Ulrich.Kuester@uni-jena.de>
   CC: public-xg-swsc@w3.org
   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-Hub-Spam-Report: BAYES_00=-2.599
   X-W3C-Scan-Sig: lisa.w3.org 1JJOfS-00049l-Pr 37e340145677d0cc77f94e984c972ace
   X-Original-To: public-xg-swsc@w3.org
   Archived-At: <http://www.w3.org/mid/479D87C1.30904@uni-jena.de>
   Resent-From: public-xg-swsc@w3.org
   X-Mailing-List: <public-xg-swsc@w3.org> archive/latest/6
   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,

   |  I agree with B) in principle, but I don't know that everyone should
   | follow your format.

   I just would like to clarify, that I never suggested everyone should
   follow my format (which is why I also pointed out flaws of my approach).
   I just suggested to come up with guidelines for a format like your
   suggestions which provide an excellent start.

   |  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.

   I don't like this one. The requirement of the existence of
   well-published specifications is a quite sloppy one. What is
   well-published? We should definitely allow everyone to use the formalism
   of their choice, even if it is not as standard as XML or KIF but - for
   instance - the rules used by Tiziana or DSD. :-)

   |  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.

   This addresses the issue of promoting reuse. That's a fair issue but I
   would like to put more importance on promoting the general understanding
   for the nature and approach of the solutions than the reuse of elements
   of them.

   |  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.

   Certainly!

   |  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.

   I agree. I would add and stress that the content should enable the
   reader to understand a particular solution on the technical level and
   preferably get a solution running (after all running and implemented
   solutions is what the challenge is about). I only get a real feeling for
   an approach if I have used it to solve a concrete problem. As an
   example, I do not only want to see the time ontologies of the other
   approaches, I want to see how they actually described the services and
   goals to get a feeling which problems have been expressed and solved how.

   Maybe we need to come up with a scenario specific list of items to be
   adressed. For discovery for instance I would really like to see all
   services and goals and I would like to see how the data-mediation and
   the integration of dynamic information was done. I would like to ask for
   a certain completeness of the upload itself and the documentation of the
   upload.

   Best regards,

   Uli
   -----BEGIN PGP SIGNATURE-----
   Version: GnuPG v1.4.3 (MingW32)
   Comment: GnuPT 2.9.2

   iD8DBQFHnYe/8VxeCU3I0jARAtDZAJ0UCSYTevx5qsLCQkE/8tRwmDs/hgCeJyRr
   amvJzvh9tBrqECd0T4DujyY=
   =fZqh
   -----END PGP SIGNATURE-----

Received on Monday, 28 January 2008 14:12:11 UTC