Re: Do we loose anything? (discussion on ISSUE-131)

Bijan Parsia wrote:
> As I understand it, there's two aspects to the proposal:
>     1) Make OWL-R syntactically distinguishable from OWL Full (that is, 
> rule out some graphs)
>     2) Bring OWL-R Full and OWL-R DL together (or as close as is feasible.
> 
> The first is criticial, the second is helpful (i.e., 1 fragment is 
> easier than 2). Everything I see in your list is related to 2). 
> Personally, if we have an OWL-R Full that is a bit more than OWL-R DL 
> (with respect to builtin vocab, punning, etc.) that would be ok by me 
> (assuming there are no other problems).
> 

Yes, this distinction is indeed helpful. And yes, my entries fall 
probably under #2.


[snip]

>
>> 1. Punning
>>
>> From an OWL-R-Full point of view, punning is of course not an issue. 
>> However, the current state of OWL2 is that object/data propery punning 
>> in DL is _not_ allowed. Doesn't that mean that, if we go along your 
>> proposal, it would be disallowed in OWL-R (if one wants to bind to the 
>> official profile) to use the same symbol for data property _and_ 
>> object property? This may be considered as a major restriction for 
>> OWL-R-Full users.
> 
> One point I'd like to raise here. I see you saying that such punning is 
> a major feature (since not having it is a major restriction). I recall 
> right after we removed object/data punning Michael gave a little example 
> of owl-r that relied heavily on it to showcase a nice feature...
> 

I do not remember this; it may have been at the f2f where this was 
discussed (and I wasn't there).


> ...given all this, shouldn't we consider adding back to OWL 2DL? I mean, 
> we technically know how to do it...there's just some extra vocabulary 
> (roughly).

I think the 'just some' was 'quite some':-) But I cannot really comment 
on the DL difficulties.

Maybe this is one of the places where "(or as close as is feasible)" 
comes in:-)

[snip]
>>
>> SELECT ?x WHERE { ?x a owl:TransitiveProperty }
>>
>> will _not_ return rdfs:subClassOf, although, well, rdfs:subClassOf 
>> walks like a duck and quacks like a duck...
> 
> Just to pick a bit on this example...would you really want this in your 
> answer? I mean, rdfs:subClassOf is a *builtin* "transitiveproperty". So 
> including it in your answer set just adds noise. Indeed, SPARQL engines 
> could build in that knowledge themselves.
> 

As I said: I was not sure. But if the decision is not to, it has to be 
clearly said and specified. Some RDF users might be surprised.

>> It is not entirely clear in my mind what an RDF user would expect in 
>> this case, and we may very well decide that this is not a major issue. 
>> But we should be clear in our mind that, well, this question may come up!
> [snip]
> 
> It's worth considering. There's similar user issues about, e.g., 
> including owl:Thing or owl:Nothing in "ancestor/descendant" queries. In 
> general, trivial theorems are a funny thing to deal with. Sometimes, 
> some people want them excluded as noise; other times, other people want 
> them for sanity checking and avoiding special casing. I don't think 
> there is an ideal answer. I tend toward a bit of minimalism.
> 
> By and large, an OWL-R Full with property punning and syntax reflection 
> would be, afaict, ok with me as long as the way its done actually has an 
> appropriate effect on entailment. The thing about the current OWL-R Full 
> that's unpalatable to me is that there's this silently ignoring of parts 
> of the graph. When the relationship is simple (simple entailment to rdf
> entailment), it's not such a big deal. When the relationship is complex 
> (i.e., you aren't just ignoring triples, but triples *in certain 
> patterns*) I think it's a horrorshow.

You mean things like existentials in the consequents? I just want to be 
sure what you mean...

Ivan

> 
> Cheers,
> Bijan.
> 
> Cheers,
> Bijan.
> 

-- 

Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf