Re: OWL-S Atomic Process/grounding issue

Hi Daniel --

You raise a good question.

The current organization was motivated by these ideas:

A process specification is conceptually independent from its 
grounding(s), and in practice may well be developed independently.

A process could be reused by many different service providers, whereas a 
grounding would be used by a *particular* provider (since it refers to a 
WSDL spec, which specifies particular network addresses).

For example, the process "BuyBook" might be used both by Amazon and by 
Barnes & Noble.  To buy a book from Amazon, you would invoke BuyBook by 
means of Amazon's published grounding, and to buy a book from Barnes & 
Noble, you would use B&N's published grounding.

So it could be somewhat misleading to publish, in the process model, a 
bunch of references to groundings that it can be used with.  Well, not 
misleading, I guess, but the point is there's some missing information. 
  A service provider needs to be able to say: "use this process with 
this grounding".  That's the whole point of the class "Service".  Each 
instance of Service is supposed to be a statement by a provider that 
says "I provide this service, and it operates according to process model 
PM, and it can be accessed by groundings G1, G2, ... GN".

In other words, if a client wants to use a service, there's no point in 
starting from a process model and then finding some grounding by which 
to access the process model.  The client really needs to start from a 
Service object, so the client will know who the provider is, and what 
grounding(s) that provider works with.  (Also, in the future I expect 
the Service class may evolve further to have other information needed by 
the client.)

So, we were concerned that it would ultimately be confusing for a 
process model to include a bunch of facts identifying groundings that it 
can be used with.  Certainly we did not want to create any expectation 
that the process model itself would include a complete list of 
groundings.  If we had a property of AtomicProces -- say, hasGrounding 
-- as you suggest, then there's some concern that this might encourage 
the practice of creating such a listing in the process model, which to 
me would be clearly a bad practice.  Conceptually the creator /publisher 
of the process model should not be expected to be aware of what 
groundings are currently in use with the process model.

Of course in OWL there's no requirement as to where the instances of a 
property exist.  So I'm open to this idea that the hasGrounding property 
(if we had it) could be instantiated in other places besides the process 
model itself.  But then I still don't see how it would be used in 
practice.  In practice, as I say above, it seems essential that a client 
will start from the Service object.

But I suppose there's room for discussion on this ...

Regards,
David

Daniel Elenius wrote:
> 
> Hi.
> 
> I am looking at the OWL-S ontology and thinking that the connection 
> between an AtomicProcess and its WsdlAtomicProcessGrounding looks a bit 
> awkward. While it's easy enough to find the AtomicProcess from its 
> corresponding WsdlAtomicProcessGrounding, by looking at the owlsProcess 
> property, there is no such property for finding the 
> WsdlAtomicProcessGrounding for a AtomicProcess. You have to see which 
> Service describes the AtomicProcess, then see which Groundings supports 
> the Service, then look through all of these to find which one has an 
> owlsProcess property pointing at the AtomicProcess.
> 
> Besides from being awkward, there is no way to express that _each atomic 
> process_ must have one or more groundings, which would be reasonable.
> 
> Why not add an inverse attribute of owlsProcess, with the appropriate 
> cardinality restrictions? Seems to me this would make it a lot easier to 
> visualize, understand, and use the ontology.
> 
> Regards,
>

Received on Thursday, 13 May 2004 20:48:42 UTC