- From: Pat Hayes <phayes@ihmc.us>
- Date: Tue, 3 Feb 2004 13:23:23 -0600
- To: Bijan Parsia <bparsia@isr.umd.edu>
- Cc: public-sws-ig@w3.org
>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. -- --------------------------------------------------------------------- IHMC (850)434 8903 or (650)494 3973 home 40 South Alcaniz St. (850)202 4416 office Pensacola (850)202 4440 fax FL 32501 (850)291 0667 cell phayes@ihmc.us http://www.ihmc.us/users/phayes
Received on Tuesday, 3 February 2004 14:23:50 UTC