Re: [TF-Ent] RIF Core Entailment section

On 2010-3-9 16:54 , Chimezie Ogbuji wrote:
> Comments below.  BTW, I forgot to mention in my last response that I updated
> that sentence in the first paragraph of 7.2 (per your suggestion to clarify
> and shorten) to:
> 
> "However, RIF-Core's syntax permits built-in functions and predicates in the
> body of a rule. Without appropriate safety conditions, cyclic references can
> rule out the existence of a single, intended Herbrand model of the
> combination and indeed various stratification and?stable
> model?theories?[STABLEMODEL]?have been defined in the literature that use a
> dependency graph to determine if a ruleset is?stratified?and incorporates
> the restricted use of built-in function symbols that allow the truth of a
> predicate to be well-defined by an external procedure."
> 
> Hopefully that reads better.

Yes, thank you.

> 
> On 3/9/10 5:19 AM, "Ivan Herman" <ivan@w3.org> wrote:
[skip]

> 
> I probably need to clear up the editorial note.  I just wanted to raise the
> point that the?common-RIF-RDF-interpretation has conditions requiring the
> interpretation of rdfs:subClass alone (separate from the other RDFS
> vocabulary). 
>

Yes, this is true and, personally, I wonder whether this is not a bug in
that document (and, afaik, Axel is discussing that). I am not sure we
should have a reference to this problem in our document, though....

>> (I actually still do not know how me as a user
>> will decide _which_ entailment mechanism an endpoint should use!).
> 
> I'm unsure myself.  In some cases, it is clear which entailment regime is
> relevant but in many cases it is ambiguous (If you have a well-formed OWL2
> DL graph with a reference to a safe RIF Core ruleset, which regime do you
> use?). 

And I think the current line of thought is: whichever the user chooses
(rightly or wrongly). In practice, I think that a sparql endpoint will
assign separate URI-s to various regimes, for example, and leave it at
that.

In any case: there might be a general mechanism but I do not think this
should be part of the specification of that particular entailment...

> 
>> 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 understanding is as follows:
> 
> 1. We form a combination C from sk(SG) and the imported strongly safe RIF
> Core document R (and all the documents it imports via rif:Import), so  C =
> <R,sk(SG)>
> 2. Let M denote *any*?common-RIF-RDF-interpretation <I',I> that satisfies C
> 3. Then the semantics of the answers are those solutions such that
> sk(P(BGP)) are RIF-RDF-entailed by M.  I.e., those triples T in sk(P(BGP))
> such that every M that satisfies C also satisfies T.
> 

Before going into details below, I do believe we have a terminological
issue, at least I have, looking at the rif-rdf-owl document again. That
document talks about 'common-RIF-RDF-interpretation' as a generic term,
and then refers to the different RDF related entailment possibilities.

Ie, what you describe is entirely correct but does not cover the whole
picture. We indeed have RIF-RDF-Simple, RIF-RDF-RDF, RIF-RDF-RDFS, and
RIF-RDF-D (plus RDF-RDF-OWL-Full...). Probably better to keep to
something like these just to clarify the discussion...

> For 2., ?'satisfaction' is defined only if I' satisfies R *and* I satisfies
> sk(SG) (via simple entailment).  So, we wouldn't entail any answers if the
> RIF Core document was inconsistent / unsatisfiable.  Condition 4 for
> common-RIF-RDF-interpretations restricts IEXT(k) (the interpretation of RDF
> triples) to coincide with the interpretation of the frames in the RIF
> document, and the other conditions further restrict the interpretation of
> the RDF graph.  So, the only entailment / satisfaction relationship that
> matters is that of simple entailment, modified to incorporate the semantics
> of the RIF constructs in R.  And this modified relationship holds between M
> and some Graph, so no merging is necessary.
> 
> As long as sk(SG) is finite, any RIF-RDF-entailed graph would also be finite
> (since the safety restrictions ensure the Herbrand model is finite by
> essentially ensuring no 'new' constants are introduced).  So the finite
> restriction would only be relevant for the infinite axiomatic triples, and
> Birte's recent modifications to C2 address this:
> 
> (C2) For each variable x in V(BGP), sk($B&L(B(x)) occurs in sk(SG) or in
> rdfV-Minus.
> 

This is necessary only if we use RIF-RDF-RDF and RIF-RDF-RDFS (and OWL).
In the case of RIF-RDF-Simple the issue does not arise, does it?

> For the purpose of the RIF RDF entailment, the only added restriction is to
> ensure that (for example) even in the face of the following SG (with a
> single statement pointing to an equally empty RIF Core document):
> 
> <> rif-rdf:usesRuleset <...rules.rif>
> 
> The query 
> 
> SELECT??x WHERE {??x a rdf:Property }
> 
> Against this graph using the RIF-RDF entailment regime will still return
> answers for the terms in rdfV-Minus.  For example:
> 
> ?x -> rdf:type, ?x -> rdf:subject, etc..
> 
> This can be achieved by (automatically) including the statements regarding
> rdfV-Minus in SG (which is very similar to what the informative RDF
> embedding in the compatibility document does for the same purpose).  So, one
> possibility is to form the combination C from sk(SG union G-rdfV-Minus)
> instead, where G-rdfV-Minus is the graph comprised of the RDF axiomatic
> triples minus those involving rdf:_n)

I must admit I do not understand that. Isn't that covered by the current
(modified) (C2) already? If we use RIF-RDF-RDF then the (rdf:type a
rdf:Property) triple is entailed by the RDF (it is entailed by any empty
graph), so the RIF-RDF-RDF common structure _will_ include that one, and
(C2) will allow that to 'go through'.

> 
>> 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...
> 
> That's what I figured as well, but would that mean some syntax or illegal
> source error is raised or that the included vocabularies that are
> incompatible with the current profile are simply not considered?
>  

Ah! That is another issue. But you already have a reference to illegal
handling and inconsistency, following the footsteps of Birte. Isn't that
enough?

>> 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.
> 
> Ok, I see.  What I was trying to describe above is a framework for RIF-based
> entailments that rely on RIF-RDF to determine the appropriate preprocessing
> and entailment relationship for other kinds of combinations.
> 

I think we are talking about the same thing:-) But the text should make
it somehow more explicit that (if we go down that route, that is, see
Birte's mail on using Simple only) your description is just a framework
that has to be combined with whatever we define for the various other
entailment regimes.

>> 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.
> 
> Yes.
> 
>> 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...
> 
> I don't have a strong reason for starting from RDF entailment other than by
> doing so, the RIF-RDF entailment regime 'extends' the existing RDF
> entailment regime (every answer that follows from RDF entailment still
> follows during the use of an RIF-RDF entailment).  The difference between
> the two is support for conditions on:
> 
> - The RDF vocabulary
> - XMLLiterals

And indeed, we should get to the same results, but the rules might cover
that...

That being said, the 'framework' approach above might require less work.
Putting the 'Simple plus explicit rules' approach as part of an informal
note might still be a good idea, so that readers should realise that,
well, we are talking about the same thing...

Thanks!

Ivan


> 
> -- Chime
> 
> 
> ===================================
> 
> P Please consider the environment before printing this e-mail
> 
> Cleveland Clinic is ranked one of the top hospitals
> in America by U.S.News & World Report (2009).  
> Visit us online at http://www.clevelandclinic.org for
> a complete listing of our services, staff and
> locations.
> 
> 
> Confidentiality Note:  This message is intended for use
> only by the individual or entity to which it is addressed
> and may contain information that is privileged,
> confidential, and exempt from disclosure under applicable
> law.  If the reader of this message is not the intended
> recipient or the employee or agent responsible for
> delivering the message to the intended recipient, you are
> hereby notified that any dissemination, distribution or
> copying of this communication is strictly prohibited.  If
> you have received this communication in error,  please
> contact the sender immediately and destroy the material in
> its entirety, whether electronic or hard copy.  Thank you.
> 

-- 

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