Re: [OWL-S]Avoiding Lists

Hi,
I nearly don't dare to ask the question, but what use is an ontology if 
you can not proof its consistency and infer new information from it? 
Currently I don't see another option than using DL-based reasoners.
What are the advantages of using OWL-full that will weight up 
consistency checking and classification?

Cheers
Florian



Pat Hayes schrieb:

>
>> If OWL-S ontologies are to be OWL-DL, then we must eliminate all 
>> "extraneous" use of the RDF collection vocabulary. (That is, we must 
>> only use rdf:List and friends in certain syntactic situations and 
>> never as a user level modeling construct.) There are three places 
>> where we do or might use collections:
>>
>> 1) As the value of the components property, especially for indicating 
>> sequences or unordered sets of processes. Note that simply avoiding 
>> subclassing rdf:List isn't sufficient. The mere use of lists puts us 
>> in OWL Full.
>
>
> Restrictions like this were SUCH a bad idea. Sigh. The torture that 
> you are now going through illustrates the reasons why.  The entire 
> OWL-S process is going to be warped in order to save the tool builders 
> the trouble of having to do some intelligent parsing.
>
>> 2)  It seems somewhat natural to describe certain parameters as 
>> consuming or returning lists of objects.
>>
>> 3) DRS may make use of lists in describing formulas.
>>
>> Disposing these in reverse order:
>>
>> 3) If DRSyly described preconditions and effect formulas are 
>> associated with a process by a datatype property whose values are 
>> XMLLiterals that contain the RDF/XML for the DRS formulas, then the 
>> parent KB will be in OWL DL even if the literals themselves are OWL 
>> Full. I think it would be better if it were DL all the way down, but 
>> hey. It's a compromise :)
>>
>> 2) Don't Do That.
>>
>> 1) Don't Do That.
>>
>> Ok, but what can we do instead of 1 or 2. Some choices:
>>
>> a) Define a shadow collection vocabulary, e.g., owls:List and 
>> friends. Use as one does the RDF collection vocabulary. If one wants 
>> compatibility with OWL Full tools, one can define an ontology which 
>> contains the requisite equivalences and simply import it when dealing 
>> with OWL Full tools. Conversely, it wouldn't be hard to write a 
>> lint-esque tool that too OWL Full kbs with modest use of the 
>> collection vocabulary that replaces those uses with the corresponding 
>> items from the shadow vocabulary. The big loss is that in OWL-DL 
>> compatible kbs, you couldn't use the parseType="Collection" short cut 
>> (note, you already can't do this for lists of datavalues). Well, boo 
>> hoo. We could publish an XSLT sheet that took care of this.
>>
>> b) Use alternative modeling altogether. For example, for sequences, 
>> we can have a sequence object where each owls:item had a 
>> distinguishing property value that allowed us to recover the order. 
>> It could be a "line number", or a "tag" (as in the surface syntax), 
>> or what have you. There'd be some tedium in representing the fixed 
>> total number of items and the distinctness of the items, but nothing 
>> too bad.
>>
>> c) Do something exceedingly clever with literals. Literals already 
>> *have* structure (both xml and the simpleType, list).
>>
>> Any thoughts, preferences, screams of pain anyone would like to share?
>
>
> Thought: Serves you right for trying to fit into OWL-DL
>
> Preference: use option (a). There is almost no semantics associated 
> with rdf:List etc. that couldnt be associated with owl:List or even 
> fred:List. To hell with parseType, its a crock anyway. Option (b) is 
> more work for no perceptible advantage, and option (c) is a Really Bad 
> Idea.  Really Really Bad.
>
> Screams of pain: I would be emitting them if I thought that I had to 
> use OWL-DL.
>
> Pat
>
>> Cheers,
>> Bijan Parsia.
>
>
>

-- 
Florian Probst

Institute for Geoinformatics (ifgi)
Robert-Koch-Str. 26-28
D - 48149 Muenster
fon_________+251 83-30058
fax_________+251 83-39763
mail________f.probst@uni-muenster.de
ifgi________http://ifgi.uni-muenster.de
personal____http://ifgi.uni-muenster.de/~probsfl

Received on Wednesday, 4 February 2004 05:17:22 UTC