Re: Proposal and Test cases (Re: skolems: visible differences?)

On 16 Jan 2008, at 15:08, Jeremy Carroll wrote:

> Hi
>
> following points came up in HP internal discussion:
>
> a) there's currently no conformance requirement to implement  
> entailment for OWL systems, and we would not expect such a  
> requirement to be introduced.

I don't understand what you mean. Presumably it's very reasonable to  
introduce a conformance requirement *for entailment checkers* (let's  
call them). This is a major function of owl tools (e.g., as a basis  
for classification, realization, etc.) and thus a point of interop.

Why wouldn't you expect we'd do this?

> Jena implements entailment principally for passsing W3C entailment  
> tests, rather than for end user functionality. The Jena  
> implementation is fairly similar to the RIF implementation: on the  
> LHS of an entailment a bnode is effectively skolemized, on the RHS  
> a bnode becomes a variable in a SPARQL query.
>
> b) Bijan's proposal seems problematic for OWL Full, because bnodes  
> corresponding to individuals get treated differently from  
> structural bnodes (for example those introduced as part of an  
> intersectionOf construct, with its rdf:List ...)

If there's no conformance requirement which is sensitive to this,  
what does it matter?

It seems like your two points are in tension: You seem to want to  
constrain specification but not enforce conformance. I'm very confused.

Can you point to a system (application or tool) which will break if  
we "break" this bit of adherence to the OWL Full semantics?

(Note, you seem perfectly happy to break OWL DL backwards  
compatibility of both tools and ontologies in order to get nominal  
OWL Full compliance (e.g., infinite OWL:Thing). Could you explain  
your (i.e., HP's) calculus for deciding what's "safe to break"?))

> c) strong support that Skolemization is a legitimate OWL  
> implementation technique, and suggestion that the OWL WG should  
> review the specs shortly before last call to ensure that nothing is  
> said that furthers the misreading that Skolemization is not  
> permitted. Some text explicit permitting Skolemizing  
> implementations may be advisable.

I don't understand the benefit of this circumlocution. "We don't spec  
it but you can, and probably should cause everyone else does, do it"?

> in summary, not in favour of Skolemized semantics; but in favour of  
> Skolemizing implementations.

I appreciate the effort you've put in, but I have a lot of trouble  
making sense of this position. In particularly, I don't see how it  
helps your *or* my interests, as I understand them. Could you explicate?

I tend to be very much against obscurity in specs. I would think we  
all default to thinking that it would be better to say what OWL  
systems actually do in the clearest way possible? So don't you need a  
rather extraordinary case if you are to achieve consensus on this point?

Cheers,
Bijan.

Received on Wednesday, 16 January 2008 15:58:54 UTC