Re: Why would the semantic web services need new logic formalisms?

Hi! And thanks for your quick reply!

I'm sorry about my offence against "formalisms". I would simply like to keep
things as simple as possible.

My intuition about the interoperability problem is that it simply takes hard
work and time to find concencus on the domain ontologies. Or rather such
concensus can not be found and thus we should find ways to develop mappings
between ontologies. And by ontologies I mean the like that can be expressed
with RDF Schema. I have not yet understood the usefulness of the description
logics.

To me it seems more feasible to develop software agents as single pieces of
software rather than as distributed modules that are combined only during
execution. It simply feels too ambitious to think that the service
composition planning could be developed collaboratively by the service
providers by combining their contributions as a single harmonious system
during the planning. Even if some logic programming language is used instead
of some more conventional procedural language.

More specific answers to your comments follow:

On 3/24/07, Bijan Parsia <bparsia@isr.umd.edu> wrote:
>
> > The overall goal of semantic web services (SWS) is that we could
> > express implicit
>
> Implicit?


I mean that we should let all implementation details unspecified and only
express the goal state that we are trying to get into. Implicit is unclear
word, that's right.

> If the ontology's are different there must be some mapping from one
> > ontology to other.
>
> And how do you express that?


I think that in general some turing complete language is needed. Parts of
the mappings could be written in some procedural language, but they should
be annotated so that their automatic discovery and combining could be
possible. This is just my intution.

> The famous example is that we want to purchase a trip from one city
> > to another. To me it seems entirely feasible to define an ontology
> > about travel services such as plane or train lines and to run query
> > about these services for example with some SPARQL query engine.
> > This query may have to be distributed, but distributed queries are
> > an old and I guess well understood problem domain. The overall
> > consensus among the SWS research field seems to be that this kind
> > of simple approach does not work.
>
> Who says that?


This is the only work that I've found about using sparql as a service
request:
http://www.w3.org/2005/11/SPDL/

Do you know of any others?

> Instead a heavy weight logical formalisms are developed.
>
> Well, if the SPARQL query is run against OWL ontologies, for example,
> then there is "heavy weight logical formalism" already in play. So
> you need to be more precise in setting up your contrast classes.
>
> SPARQL itself is a fairly complex logical formalism.


Yes SPARQL is complex, but it's so close to SQL that I think it's clear that
it works in practice.

> For example it is proposed that a rule language is needed for
> > expressing that a certain type of credit card needs to be provided
> > to use a certain service. To me this seems simply a matter of
> > defining such an ontology
>
> In what formalism?


Maybe I should not talk about ontologies but about data schemas. So I would
stick with RDF Schema. Or maybe RDF vocabulary rather than schema is more
appropriate term.

> in which this requirement can be expressed.
>
> That's the issue, eh? It has to be expressed in a manner sufficient
> to allow for the desired behavior.
>
> > The set of valid credit cards could be a property of the service
> > and the agents or mediators that understad the ontology must know
> > that any valid request must include a pointer to one of these
> > credit cards.
>
> And how do you accomplish all this?


I think it would be enough to write this requirement in plain english. The
agent can simply be hard coded to produce walid trip reservations for this
particular domain ontology. It can then operate on services that adhere to
this ontology and with other services with the help of appropriate
mediators.

> The automatic service composition may be a good application domain
> > for classical planning algorithms. Simple planning based on input
> > and output types of services is certainly possible. But other
> > applications of logic programming paradigms in the field of SWS do
> > not seem to be that well justified.
>
> While that may be true, I don't see that you've established the
> point. You (implicitly) *claim* that "ontologies" are more
> lightweight, but without any description of the ontology language,
> you don't get to assume that.


I explained my view about ontologies above. SQL table definitions are like
the ontologies that I'm thinking about here.

I would like to see practical applications for description logics.

Plus, take, just for example, OWL-S. You describe some of the aspects
> of a service using fairly vanilla OWL. But preconditions and effects
> generally require a bit more machinery.



> > It seems that the goal of extensive formal service descriptions is
> > that services that are described with them could be used by a
> > software agent that is not specifically developed to understand the
> > related domain ontology.
>
> Well, if part of the related domain ontology are descriptions of the
> *actions* one might take and their *consequences*, then perhaps. It
> might be better to say that service descriptions are one way *you
> build domain specific software agents* with a certain level of
> flexibility. That's certainly one view of, e.g., HTN planning.


So the SWS approach to the planning problem is to let the service providers
collaboratively develop the software agent that plans the use of the
services. Has this kind of software development process been tried
elsewhere? It seems quite ambitious.

> I think a more appropriate or at least practical focus should be on
> > how to define, and automatically apply ontology mappings and other
> > mediators rather than trying to cope without shared ontologies.
>
> Again, what's in your ontologies? If they don't have enough to
> support reliable manipulationg, then there's no point. If they do,
> they're are going to be roughly expressive, I'd warrant, as at least
> the weaker current description languages.


What do you mean by reliable manipulation?

> The formalisms such as SWSL and WSML can be seen as an effort to
> > develop tools for ontology mapping, but there is a danger that we
> > over emphasize declarative programming paradigms. If declarative
> > programming would be applicable to large scale real world problems,
> > I would expect there to be more evidence on that.
>
> SQL, XSLT, XQuery, XML Schema, BPEL (sorta), CDL....


Yes of course declarative programming can work. That was foolish claim from
me.

The general purpose logic programming languages that are used to define
preconditions and effects in OWL-S and SWSF are the kind of declarative
languages that I'm affraid of. I have understood that large rule bases are
hard to manage. If such rule programming is applied on semantic web service
descriptions there is no way to test all service descriptions (rule sets)
together beforehand. I would think that it's quite hard to make the rules
work together if you can not expect what rules the other service
descriptions provide.


> In any case, popularity doesn't determine applicability.


That's true of course. But has there been some recent advancement in the
field of logic programming languages so that their applicability has not yet
been noticed by the general public?


Regards,
Jukka