Re: [TF-Ent] RIF Core Entailment section

On 2010-3-8 16:53 , Chimezie Ogbuji wrote:
> Comments below
> 
> On 3/8/10 5:32 AM, "Ivan Herman" <ivan@w3.org> wrote:
>> You have an editorial note right after the definition that refers to
>> rdfs:subClassOf. I am not sure where we are with that, maybe Axel and
>> Sandro can help out, but that was discussed on the list for while.
>> Indeed, in my personal view, it is not kosher to have that reference
>> there, because that clause in the RIF-RDF interpretation does not talk
>> about RDFS vocabularies. So this might go out of the proposed rec, I do
>> not know...
> 
> "Condition 8 ensures that whenever a RIF subclass statement holds, the
> corresponding RDF subclass statement holds as well, i.e., a rdfs:subClassOf
> b is true if a ## bis true."
> 
> It seems that the RIF-RDF common-RIF-RDF-interpretation and
> rdfs-interpretation is meant to be mutually exclusive interpretations of a
> vocabulary although they refer to the same vocabulary term in some of their
> conditions: rdfs:subClassOf.
> 
> If a query was against an SG with rdfs:subClassOf but no reference to a RIF
> document, then it is clear that the rdfs-interpretation is being used to
> determine the answers.  Otherwise, I think you can safely assume the use of
> the common-RIF-RDF-interpretation.  Unless it is unclear which of those
> scenarios the query author had in mind, it should be okay to interpret that
> term differently depending on the context.  They (more or less) amount to
> the same relation, but we probably should elaborate in the note and point to
> a good point in the list where the discussion happened.
> 

Hm. I think that is a different issue. You seem to suggest that the mere
presence of an rdfs: vocabulary term in the default graph should trigger
the rdfs interpretation for the SPARQL endpoint. I do not think we ever
had that discussed... (I actually still do not know how me as a user
will decide _which_ entailment mechanism an endpoint should use!). My
mental has always been that the user has to choose the entailment regime
explicitly

[skip]
> 
>> The starting point of my problem is: why do we need (C2) for the RIF-RDF
>> case?
> 
> I don't think we do for the RIF-RDF case now that I think about it.
>

I actually think we do! My understanding of the RIF-RDF entailment
mechanism is that, conceptually, two different entailment processes
would operate (controlled by the conditions that bind the two, as
described in the RIF-RDF document) and the results are, sort of, merged
at the end. As a consequence, any conditions that we needed for RDF
entailment to avoid going to infinity applied to this case as well.

My point is that we do not need it for Simple entailment.


>> However, we would not need (C2) if our definition was based on the
>> simplest combination, ie, the RIF-RDF with Simple Semantics. Is that
>> correct?
>> Which begs the question: what is the level of RDF entailment that we
>> should define? Don't we have, in fact, separate entailments with RIF
>> Core combined with RDF, RDFS, and OWL Full/DL?
> 
> I think we should start with the RDF profile ( RIF-RDF-entailment ) - i.e.,
> the first level above simple entailment + RIF Core.  Anything above that
> would need to be distinguished from (or synchronized with) the other regimes
> in the document that use rdf-interpretations and rdfs-interpretations, etc.
> 
>> (I wonder whether, editorially, we could not just create some sort of a
>> generic structure for RIF + the others, by referring to the RIF-RDF
>> Combination document.)
> 
> We could do that, but I think we might (if we wanted the language to be
> normative) have to address the difference between SPARQL against (SG ->
> RIF-Core doc with use of RDFS profile) and against (SG with RDFS), etc.  I
> do think the criteria for legal graphs might need to be expanded to rule out
> problems in the (full) import closure: for instance, the RIF-Core document
> referenced has additional imports (with profiles higher up in the precedence
> above RDF).  
> 
> Otherwise, we could (in an informative section), setup this kind of a
> structure for "SPARQL extensions for RIF embeddings":
> 
> Entailment:  The entailment relationship associated with the greatest
> profile [1] used in the import closure of the referenced, safe RIF-core
> document (using the precedence order of the profiles specified in the
> compatibility document)
> 
> Query answers: The RDF triples sk(P(BGP)) are ground and ____ entailed by
> the combination formed from sk(SG) and the safe RIF core document referenced
> from SG.  Where the entailment is specified by the profile of greatest
> precedent.
> 
> In each case, we would have to work backwards (through the Embeddings of
> RDFS, RIF DL-document, etc.) to ensure they meet the entailment regime
> conditions (especially as it relates to Blank nodes and finiteness of
> answers).
> 
> Is this what you had in mind?
> 

I am not sure I understand your reasoning, but I wonder whether this is
not related to the point above. As a user I am supposed to choose which
of the entailment regime I would ask for and, from that point on, things
are fixed. If, during the import, I get to vocabularies that are not
interpretable with the entailment regime I chose then, well, tough luck...

So no, this is not what we had in mind... But something rather like a
template for RIF which says: We use strongly safe RIF Core, RIF may
require some additional restrictions on SG (not sure that is true), and
RIF may be combined with any of the entailments defined in this document
to form a pair (ie, inheriting the possible restrictions), whose
semantics is formally defined by the RIF-RDF document published by the
RIF WG.

>  
>> Another possibility is to restrict ourselves to RIF and Simple Semantics
>> and make it clear (I believe that is true) that is it possible to define
>> a RIF rule set that covers RDF and RDFS semantics with the restrictions
>> that we have for them;
> 
> I believe with RIF-RDF entailment, you can already include arbitrary (but
> safe) RIF core rulesets that would be expressive enough for most of RDF /
> RDFS semantics without relying on the (informative) embedding mechanisms.
> The primary concerns are the at-risk conditions (having to do with RDF / RIF
> lists) and rdfs:subClassOf - which I think is abuse of notation at worst.
> 

To come back to my point: why do we need RDF entailment? Isn't it true
that if we define RIF-RDF Simple, we can also informally publish RIF
rules that implement RDF, RDFS, etc, including the restrictions that are
defined elsewhere in this document. Ie, if I have a pure RIF engine at
the endpoint that understand RIF-RDF simple (essentially, how RDF is
expressed in RIF), I can have RDF/RDFS/OWL 2 RL entailment done by
supplying a bunch of RIF Rules...

This may be an alternative to the editorial changes we discussed above...

>> the sparql-rif:useRuleset seems to be necessary now, but I would prefer
>> not to bind this to sparql. Ie, it should be sometimg like
>> rif:useRuleset or rif-rdf:useRuleset...
> 
> Okay.  Do you have a base URI in mind?

Nothing particular but we can mint one when we get there... And I think
we should get an agreement on it with RIF WG. It should not be a SPARQL
decision

[snip]
>>
>> I am more bothered by your reference to RIF BLD.
> 
> That was mainly from my reading of "Simple, RDF, and RDFS entailment for
> RIF-RDF combinations are embedded in RIF Core. RIF-OWL 2 RL combinations
> require reasoning with equality, and thus could not be embedded in RIF Core;
> they are embedded in RIF BLD." (in 2nd para of 9 Appendix: Embeddings
> (Informative))

I did not find a reference to that. Where is it? And I am not sure it is
correct: afaik (but you RIF guys should tell me!) owl:sameAs is _not_
identified with equality in the RIF-OWL combination, ie, for RL... (at
least I have not found it, though it may be the issue of buying a new
pair of glasses...:-)

> 
>> Dave's document[1]
>> explicitly says that the rule set there is RIF _Core_. It uses
>> owl:sameAs in the consequent (not '='), though it uses '=' when
>> referring to some predicates in the conditions:
>>
>> ?ix = External(func:index-of(?l ?x))
>>
>> but these seem to be artefact of list management. Doest that make the
>> rule set unsafe? Or worse, not Core? (In which case there is a bug in
>> [1] which explicitly refers to Core...)
> 
> Judging from the RIF Core syntactic restrictions "Equality terms and class
> membership terms cannot occur in rule conclusions -- they are allowed only
> in rule premises." and (normative) safety, It depends on whether or not
> there is a 'safety' chain from each of the arguments used in the equality
> (?ix, ?l, and ?x)  I can't tell from first sight.

As far as I can see there is no equality in the conclusions. There are
usages of owl:sameAs, but that term gets its 'semantics' from the OWL 2
RL rule set itself.

I am not sure what safety chain you refer to:-( As far as I could see
these are only predicates that unbind lists and get to the list indeces.
As a RIF layperson (and, well, implementer of RL:-) I do not see any
problem there...

Ivan


> 
> [1] http://www.w3.org/TR/2009/CR-rif-rdf-owl-20091001/#Specific_Profiles
> 
> Chime
> 

-- 

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