W3C home > Mailing lists > Public > public-sws-ig@w3.org > November 2004

Re: OWL-S version 1.1 now available

From: Ian Dickinson <ian.dickinson@hp.com>
Date: Sun, 21 Nov 2004 00:26:19 +0000
Message-ID: <419FE0AB.7030801@hp.com>
To: Daniel Elenius <daele@ida.liu.se>
Cc: public-sws-ig@w3.org

Daniel Elenius wrote:
>  [snip]
> And also
> ds:ClosedList a owl:Class
>             ; rdfs:subClassOf ds:List .
> right?
'Fraid not.  The first/rest/nil construct already gives you a closed 
list.  The  most common way to do a bag-like construct in OWL/RDF is to 
use a repeated property, but this has the drawback (some say, others 
disagree) that under the standard open-world assumption, you never know 
how many values there are:

     a ex:Bar
     ; ex:hasArg "1"
     ; ex:hasArg "2"

How large is the bag of arguments of foo? Answer: no less than 2.  If, 
however, you encode the args as a list, it's a closed construct and you 
know exactly the size of the list (or bag, if you mean to interpret it 
that way).

>> service:ConrolConstructs
> Do you mean service:ControlConstruct (i.e. the same as in the 
> allValuesFrom restriction below)?
No, I meant the plural.

> Or service:ControlConstructs (plural, 
> i.e. something different)? In any case, I guess it should be the process 
> prefix, but that's a minor point.
Well, it's an alternative to ControlConstructBag which isn't, at my 
quick inspection, in any of the .owl ontologies, so I had to take a 
guess at which namespace was intended.

> I don't quite see how you want to use this class. Is it a superclass of 
> all the control construct classes? Or does it replace the 
> ControlConstructBag 
Yes, it replaces(**) ControlConstructBag - it's a ds:Bag and it contains 
ControlConstruct resources.

> If so, it still looks like you would need 
> two different classes to separate between the ordered and unordered 
> cases, right?
If that's an important distinction to be made, then yes.  I'm simply 
advocating that the distinction not be made solely by parsing the name 
of the class.  URI's are supposed to be opaque :-)


(**) remember, these is just an off-the-cuff suggestion to illustrate a 
point, not a formal proposal to refine the language
Received on Sunday, 21 November 2004 00:27:00 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:54:14 UTC