Re: OWL-S in protege?

On Jan 28, 2004, at 5:55 AM, Sean Bechhofer wrote:

> The following may be of use here. It details our experiences of trying 
> to 1) validate the OWL-S ontologies and 2) load them into our tool. 2) 
> is perhaps of less interest as the restrictions are due to our 
> particular implementation. 1) is likely to be of more interest, 
> however in the context of this thread (and message 
> http://lists.w3.org/Archives/Public/public-sws-ig/2004Jan/0103.html)

Thanks Sean. I've done a fair bit of this work, but it helps to have 
your attempt as well.

I generally check a DLized file against both your species checker, and 
Pellet.

> ---------------------------------------------------------------------
>
> This document describes the steps necessary to load the OWL-S 1.0
> ontology set [1] into OilEd 3.5.5 [2].
>
> The process has two phases:
>
> 1. Getting the OWL-S ontologies (Service.owl, Profile.owl,
>    Process.owl, Grounding.owl, time-entry.owl) to validate as OWL-DL
>    with the OWL-Validator [3]


> 2. Some changes also need to be made to load an OWL-DL ontology to
>    OilEd due to some existing limitations.
>
> The lesson for OWL-S is that most of the violations of OWL-DL have to
> do with mistakes in the representation rather than adding
> expressivity.

This is known. As I said, it's largely, though not entirely, a result 
of converting from wild and wooly DAML+OIL files.

> Therefore, it is advisable to reconsider all features of
> OWL-S that push the ontology to OWL Full, especially since there are
> few reasoners or editors that would cope with OWL-Full at the moment.

Yes.

> The lesson for OWL is that even engineers of OWL-Full ontologies
> should carefully consider the validation messages one-by-one. Messages
> introduced by syntactical errors cannot be distinguished from messages
> that point to places where OWL-DL is violated "on purpose", i.e. for
> adding to the expressive power of the ontology. Some intelligence
> could be added to the Validator that highlights those messages which
> are most certainly introduced by languages abuses (such as using
> rdf:Property).

There is one instance of this where the use was deliberate (i.e., 
wanted to model that a parameter (or parameterType) can be either a 
datatype or a class), the rest are legacy.

> The "fixed" ontologies that are ready to be loaded in OilEd can be
> found at http://www.cs.vu.nl/~pmika/owl-s/. (Fixed means that they
> validate as OWL-DL with the OWL-Validator [3]). Note that if you
> download the ontologies to the disk, the pointers (URIs) in the
> owl:Ontology and owl:imports definitions need to be changed
> appropriately.

Yay! Thanks! Saves me some work.

> General comments
>
> -- Some of the ontologies lack an xml:base declaration, which puts the
>    elements into the namespace of the source file. This is not a
>    problem if the ontology is loaded from its original location on the
>    web, but it becomes a problem loading it from disk.

This is also on my fixed list.

> -- time-entry.owl should say <owl:Ontology rdf:about="" > instead of
>    just <owl:Ontology>, which creates a blank node

Ooo, missed this.

> DL violations
>
> -- Service.owl redefines rdf:Resource when it uses it as a
>    domain/range of provides/providedBy.

Known.

> -- All ontologies use at several places rdf:Property instead of
>    owl:ObjectProperty or owl:DatatypeProperty. This is reason enough
>    to fail validation...

Most are legacy, one is choice, my current belief about the will of the 
coalition is that we'll use two properties for the one place where it 
is choice.

> -- Service.owl uses rdfs:List as a superclass for ProcessComponentList
>    and ProcessComponentBag and as a range for sameValues.

This is in dispute. I have a couple of alternatives.

> -- Grounding.owl uses rdfs:List as a superclass for
>    WsdlInputMessageMapList and WsdlOutputMessageMapList
>
> -- Service.owl has a restriction on rdfs:first and rdfs:rest for the
>    class ProcessComponentList and ProcessComponentBag.
>
> -- Grounding.owl has a restriction on rdfs:first and rdfs:rest for the 
> class WsdlInputMessageMapList and WsdlOutputMessageMapList

Same as above.

> -- Service.owl defines the name property to range on
>    rdfs:Literal. This can be fixed by having its range redefined to
>    xsd:String.

Known.

> -- Profile.owl does not define the has_process property as either
>    owl:ObjectProperty or owl:DatatypeProperty. Note that
>    owl:FunctionalProperty is not enough on its own!
>
> -- Grounding.owl does not define the wsdlInputs,  wsdlOutputs,
>    owlsProcess, wsdlOutputMessageParts, wsdlInputMessageParts
>    properties as either owl:ObjectProperty or
>    owl:DatatypeProperty. Note that owl:FunctionalProperty is not
>    enough on its own!

Known.

> -- Grounding.owl defines the DatatypeProperty xsltTransformationString
>    and xsltTransformationURI to be subProperty of the
>    xsltTransformation property, which is defined to be an
>    ObjectProperty. (Likely to be a flaw in the ontology design.)

An error, at least.

> Changes needed due to limitations in OilEd
>
> -- OilEd 3.5.5. cannot deal with cardinality constraints on a
>    DatatypeProperty. In Process.owl this effects name at Process and
>    invocable at CompositeProcess. In Grounding.owl this effects
>    portType and operation at WsdlOperationRef, wsdlMessagePart and
>    xsltTransformation at WsdlInputMessageMap and
>    WsdlOutputMessageMap.
>
> [1] http://www.daml.org/services/owl-s/1.0/
> [2] http://oiled.man.ac.uk/
> [3] http://phoebus.cs.man.ac.uk:9999/OWL/Validator
>
> Cheers,
>
> 	Sean Bechhofer
> 	Peter Mika [pmika@cs.vu.nl]

Thanks. Very helpful.

Cheers,
Bijan Parsia.

Received on Wednesday, 28 January 2004 08:05:01 UTC