W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > October to December 2010

Re: Proposed change to the OWL-2 Direct Semantics entailment regime

From: Bijan Parsia <bparsia@cs.man.ac.uk>
Date: Tue, 30 Nov 2010 14:40:46 +0000
Cc: SPARQL Working Group <public-rdf-dawg@w3.org>
Message-Id: <5A94D675-EEA8-4AD5-8F23-E4D74011FA18@cs.man.ac.uk>
To: Enrico Franconi <franconi@inf.unibz.it>
[Chairs, please let me know when to take it off list]

On 30 Nov 2010, at 14:20, Enrico Franconi wrote:

> On 30 Nov 2010, at 13:16, Bijan Parsia wrote:
> 
>> On 30 Nov 2010, at 09:57, Enrico Franconi wrote:
>> 
>>> Currently, bnodes in a BGP bind only to individuals or other bnodes. According to the formal semantics (and the spirit) of RDF, bnodes represent existential (but unknown) information. If the information is encoded in RDF (or in other simple languages where existential information can always be uniquely and exactly materialised explicitly as bnodes, like RDFS and OWL-RL) then the existential meaning of bnodes in queries is correctly captured by binding them just to individuals or other bnodes. However, in OWL-2 Direct Semantics entailment regime a lot of existential information remain necessarily implicit, and we would weaken the notion of answer (wrt standard OWL-2 Direct Semantics entailment regime in 25 years of description logics literature) if we do not treat bnodes in BGPs properly.
>> 
>> I'd prefer a more neutral term, such as "treat bnodes in BGPs according to a straightforward extrapolation from the RDF semantics". I would argue, myself, that that isn't the proper way to treat them. Indeed, I would argue (and have a lot) that it's not the proper way to treat them in RDF graphs :)
> 
> uh? If you look at the model theory of RDF, being existentially bound is exactly the semantics of bnodes.

Yes, but I think the proper way to treat bNodes is to willfully violate the spec.

[snip]
> As a theoretician, if you think to classical entailment as inclusion between models, then you have no other choice than to agree with me. 
[snip]

As an interested party, I really don't. I think what's best overall for SPARQL is not to respect this interpretation of bNodes.

[snip]
>> And most users experience and expect the BNodes.
> 
> They can get them by using the OWL-DS entailment regime as defined in the current semantics.

Since I think there are no other users, I really don't see the point of including the alternative.
[snip]
>> OTOH, standards body should do some picking and choosing. The practical pain induced by having non-distinguished variables is far too high for any known benefits (see the above).
> 
> This group is standardising something that has never existed in the literature. I agree that the outcome is nice and sound (and it follows your "story"), but it is utterly useless to anybody willing to work with *proper* BGPs in OWL-2 DS (see my very simple example)

Right, and in my experience there are no such users. When users want/need existential semantics, they are happy to use a class expression. More complex patterns have absolutely no users.

People don't switch to Pellet from KAON2 (for example) to get non-distinguished variables.

Really, the evidence is overwhelming. That's *why* I changed my mind.

[snip]
>  Without this addition, SPARQL2 can never be adopted by any of the DB centric applications based on ontology based access technology, since all of these technologies do assume BGPs with proper existential variables. We would loose the entire ontology-based DB integration market based on OWL-DL.

I find this prima facie unbelievable. First, nothing prevents you from adding such a feature. It can be a nice differentiating feature, in fact. Second, I'd really love to see the mailing list or whatever where this is discussed with users. Or the collection of use cases. Show me.

>> So, I think it's a disservice to introduce them into these documents.
> 
> To whom is this a disservice? I guess that this is the heart of the discussion with you: I'm proposing to add something simple and clear to the current status of the standard, while retaining the current functionalities. I don't see who's going to suffer here if we do so.

Proliferation of regimes is generally a negative. Futhermore, it might encourage people to implement something "because its in the standard" which I think is a waste. 

I don't see the benefit. Indeed, I don't see the benefit to anyone.

I don't see that it would pass a CR phase.

Now, I don't think I'd do anything silly. We have widely ignored parts of standards (e.g., the existential semantics of bNodes).

[snip]
>> In over 6(!) years of teaching and evangalizing non-distinguished variables, I've not been able to come up or have anyone come up with a compelling example (or even a naturally occurring example) that wasn't tree like and then only by backporting an existential restriction. That suggests that, at the very least, it's premature to standardize.
> 
> You may be a very bad teacher, I guess :-)
> I don't want to go along the lines on who's a better teacher.

Yeah, that was rather inappropriate.

[snip]
>> Also, I'd be very surprised if implementors wanted to support this. I personally think Pellet should rip out that bit of implementation.
> 
> Be surprised: the academic, industry, and system people working on OWL-QL-based systems are already very upset by the limitation of the current version of the standard, and asked me to discuss the matter with the group.

Can you put me in contact with them? Mediated communication isn't very efficient.

>> Finally, since it's so well defined and understood its not like if it becomes suddenly known useful that there'd be any barrier to implementations picking it up.
> 
> I fail to understand this argument. Why are we standardising something, if it is already well known? Maybe to facilitate interoperability of acknowledged technologies? :-)


Standardization is neither a necessary or sufficient condition for interop. Show me a reasonable set of implementations and I'll think again.

Cheers,
Bijan.
Received on Tuesday, 30 November 2010 14:41:02 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:44 GMT