Re: On the functionalities of the OWL RL profile

Ian Horrocks wrote:
> It's a good point. The original brief when designing the profile/rules
> was to cover as many features as possible. Clearly, from the point of
> view of the profile design, it would be easy to remove reflexivity from
> the features supported -- the question is whether this is a feature that
> users really want or need. My guess is that most users would be willing
> to sacrifice it, given the potential performance hit, but I would like
> to hear other opinions on that.
> 

Absolutely, me too...

Maybe the simplest way of achieving this is to make an explicit call for
the community at review time drawing attention on this issue. Ie, asking
the community to give us feedback on the various functionalities that we
may consider 'at risk'.

> A similar question arises w.r.t. the RDF axiomatic triples and
> entailment rules. For example, rules rdfs4a and rdfs4b mean that:
> 
> T(?x, ?p, ?y)    
> 
> =>
> 
> T(?x, rdf:type rdfs:Resource)
> T(?y, rdf:type rdfs:Resource)
> 
> Although these triples are relatively harmless, in the sense that they
> typically won't lead to any additional inferences, they do cause a
> significant blow up in the number of triples (up to three times,
> although typically rather less).
> 

Yes. But this is more the issue whether we should have those at all (in
fact, simple, RDF, RDFS entailments refer to different axiomatic triples
ie, in fact, the choice may be a multiple one...). Ie, ISSUE-116, still
open...

Ivan


> Regards,
> Ian
> 
> 
> 
> On 25 Aug 2008, at 14:23, Ivan Herman wrote:
> 
>> Ian,
>>
>> I changed the subject line because this is not on the unification issue
>> and I do not want the tracker to pick it up...
>>
>> This reflects some discussions we had with Boris but off-list. The
>> current OWL RL is relatively large, eg, if one looks at the rule set.
>> More to the point, it may add quite a number of extra triples to the
>> store (at least conceptually). Maybe it is worth looking at the
>> functionalities with a critical eye to see whether it is worth having
>> them there (although I am fully aware that this is difficult and a bit
>> subjective...).
>>
>> The specific issue that came up is the possibility of having a reflexive
>> property. This leads to the
>>
>> T(?p, rdf:type, owl:ReflexiveProperty)
>> T(?x, ?y, ?z)    
>>
>> =>
>>
>> T(?x, ?p, ?x)
>> T(?y, ?p, ?y)
>> T(?z, ?p, ?z)
>>
>> rule, ie, the existence of a single reflexive property would add a huge
>> number of triples to the triple set. Although this is technically
>> perfectly fine, I was wondering whether it is o.k. to have it there (of
>> course, one argument might be that if the user does not want this think
>> than, well, (s)he should not use it...). Boris, in a private mail, told
>> that reflexive properties are not necessary for OWL RL in general, he
>> just copied there in the first draft.
>>
>> This may be the only example and, if so, we may just want to let it as
>> is. But it may be worth looking at the various features with a critical
>> eye to see if it is necessary to be there...
>>
>> Just a thought. Maybe it is worth raising it as a separate issue.
>>
>> Thanks
>>
>> Ivan
>>
>>
>> Ian Horrocks wrote:
>>>
>>> We (Alan and I) agreed that it would help to clarify this issue and to
>>> inform our discussion on Wednesday if the Profiles document [1] were
>>> updated to reflect the proposed "unification". This has now been done.
>>> It should be read in conjunction with the (draft) conformance
>>> definitions [2].
>>>
>>> Regards,
>>> Ian
>>>
>>> [1] http://www.w3.org/2007/OWL/wiki/Profiles
>>> [2] http://www.w3.org/2007/OWL/wiki/Conformance
>>>
>>
>> -- 
>>
>> 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
> 

-- 

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

Received on Monday, 25 August 2008 14:14:58 UTC