Re: Some advice on inferring negated properties

On Aug 16, 2007, at 8:20 PM, Swanson, Tim wrote:

> Bijan,
>
> Thanks for the reply. I found it enlightening to say the least. I
> haven't kept up to date on the developing features of OWL 1.1. We
> probably won't use it in-house until it reaches the recommendation
> stage.

Oh, I'd expect that for production systems, CR will probably be  
stable enough. (CR is likely to be short given the wealth of  
implementation experience we already have.) Much of the futzing now  
is around the edges and on some aspects of syntax.

If there are OWL 1.1 features you would find valuable, it's worth  
telling the proposed initial team contacts and/or proposed initial  
chairs of the proposed working group (I so propose):
	http://www.w3.org/2007/06/OWLCharter

Sandro is probably the best person to contact.

> However, I do follow the discussions on this list, and feel that
> the standard will be good. It already incorporates a lot of the  
> problems
> that we've encountered trying to data model using OWL.

Great! That's valuable information.
[snip]
>> That's one way. (OWL 1.1 lets you do others.) I mentioned it in my
>> email:
>> 	"""ClassAssertion(a, ObjectComplementOf (ObjectHasValue(P,
>> b)))""""
>>
>
> This was an addition I wasn't aware of.

That's just the new functional syntax, which is axiom oriented rather  
than frame oriented, and fully explicitly typed, rather than somewhat  
implicitly typed.

NegativeClassAssertion is the strictly new syntax (although it is  
sugar for the nominal form you were using).

>> From a modeling standpoint, ObjectComplementOf is great. While you  
>> can
> imitate it, it requires brute force and/or preprocessing in all but  
> the
> most trivial cases (such as the one outlined above).

Ah, that's the class one. I.e., ObjectComplementOf is just the old  
complementOf. However, there *is* both property *assertion* negation;
	NegativeObjectPropertyAssertion
(which is like the hasValue encoding...it negates a *specific* object  
property relation) AND property disjointness:

	<http://www.webont.org/owl/1.1/owl_specification.html#6.2>
	DisjointObjectProperties

Which, well, at this time at night at least, I don't see can be  
paraphrased into oldOWL. Hmm. Ok if you did some disjoint ranging and  
domaining, that would entail disjoint properties.

> Is a complement property a full-fledged property (as an object  
> class is
> a full-fledged class)?

Yes.

> Can you add subproperties to it, for instance?

Yes.

There are restricted property chains as well, i.e., property  
composition.

> This would result in a much richer property model

Yep. Properties are *much* enhanced in OWL 1.1. A property chain  
example (from Galen):

<rdf:Description>
         <rdf:type rdf:resource="&rdf;List"/>
         <rdf:first rdf:resource="#hasLocation"/>
         <rdf:rest rdf:parseType="Collection">
             <rdf:Description rdf:about="#isLayerOf"/>
         </rdf:rest>

         <rdfs:subPropertyOf rdf:resource="#hasLocation"/>
     </rdf:Description>

i.e.,

if x hasLocation y and y isLayerOf z, then x hasLocation z.

> and, as an ardent OWA
> fan, would all by itself make OWL 1.1 worth the price of admission  
> in my
> opinion.

Cool.

[snip]
>> (It's a a bit less pleasant in RDF/XML as you have to reify...here's
>> hoping for better solutions. The abstract syntax and the XML syntax
>> aren't so bad.
>>
>
> I've noticed a tendency in the hardcore OWL/RDF community to focus on
> both OWL and RDF as abstract data models, and to view the output as a
> low-level representation that's only of interest to machines.

I guess I'm not in the hardcore OWL/RDF community :)

> (The
> debate on this list over using tools vs. text editors in relation to
> "declaredAs" underscores this point.) While this is technically  
> correct,
> it is not the whole story.
>
> We use RDF/OWL as a messaging format in distributed systems. As  
> such, we
> use the RDF/XML format exclusively. (This is why I gave my example  
> above
> in that format; it's only one I have a confident competence with.)  
> While
> the messages are certainly generated and consumed by machines,
> developers need to be able to look at them during testing and  
> debugging.

Yep.

> In a development environment, it is often helpful to be able to not  
> only
> read, but also write, small snippets of RDF/OWL. A readable syntax  
> is a
> must in this case. (Note that it does not need to be intuitive, merely
> readable and learnable.)

Yep, and this is different for different user types.

> Obviously, things like serialization are best tackled /after/ the
> abstract syntax is finalized, but as you go forward, I implore to  
> not to
> ignore issues like readable serialization. (For the record, I like
> RDF/XML just fine except for rdf:ID, and the OWL 1.0 RDF serialization
> is pretty good too.)

The RDF Mapping is still being developed, but backward compatibility  
with OWL/RDF is a strong goal. Some things are just hard (e.g., axiom  
annotations).

There is also an XML syntax:
	http://webont.org/owl/1.1/xml_syntax.html

(ergh...have to clean up the examples). If you use a default  
namespace, it's pretty decent (and basically a transliteration of the  
functional syntax:

<SubObjectPropertyOf>
         <SubObjectPropertyChain>
                 <ObjectProperty owl:URI="#owns"/>
                 <ObjectProperty owl:URI="#has_part"/>
          </SubObjectPropertyChain>
          <ObjectProperty owl11xml:URI="#owns"/>
   </SubObjectPropertyOf>

Now, I think with a slight redesign we could get ride of some of  
those inner types and get closer to:

	SubObjectPropertyOf(SubObjectPropertyChain(owns, has_part), owns).
But I digress :)

One of my reasons for wanting a "plainer" XML syntax is precisely for  
web services contexts where the XML oddities of RDF/XML are a huge  
barrier.)

[snip]
> I've seen a lot of teeth gnashing, hair pulling sort of discussions on
> this list, and I thought it may help to know that there are those  
> of us
> out there who are fans of your collective work and are eagerly  
> awaiting
> the completed standard.

That's gratifying. Thanks.

Cheers,
Bijan.

Received on Thursday, 16 August 2007 23:27:16 UTC