Daniel Elenius wrote:
> Of course, but that happens all over the place in OWL-S. An OWL-S
> document is not much use without an OWL-S-aware processor. Looking only
> at the RDF level, there is also no difference between Split, Split+Join,
> Choice, and Any-Order, except their URIs. So, using the same reasoning,
> would you want to turn them all into one class?
I didn't say turn them into one class. I suggested, and it's *just a
suggestion* that one could be made a sub-class of the other, wlog.
> So, how would you do it?
Well, in a sense that's not up to me. I'm just giving you some feedback
from someone not involved in the day-to-day design and development of
the standard. The OWL-S committee has range of possible, valid,
responses to such feedback, a range which includes, among others,
ignoring it.
Fwiw, I guess I was thinking that cleanly separating utility encodings,
like "this is a closed bag", "this is a closed list" into one package,
and then re-using those in the main profile would potentially make life
easier for developers (particularly OWL-S tool developers).
For example (again *just a suggestion*), using N3 for compactness and
assuming a namespace "ds" for owl-s data-structures:
ds:List a owl:Class .
ds:first a own:ObjectProperty
; rdfs:domain ds:List .
ds:rest a owl:ObjectProperty
; rdfs:domain ds:List
; rdfs:range ds:List .
ds:nil a ds:List .
ds:ClosedBag a owl:Class
; rdfs:subClassOf ds:List .
service:ConrolConstructs
a owl:Class
; rdfs:subClassOf ds:ClosedBag
; rdfs:subClassOf
[ a owl:Restriction
; owl:onProperty ds:first
; owl:allValuesFrom service:ControlConstruct
]
.
This is, to be fair, almost the same as the current proposal. The only
difference, on reflection, is that "Bag" or "List" moves out of the URI
of the class and into an rdf:type declaration.
Ian