Re: [TF-Ent] RIF Core Entailment section

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.

On 3/9/10 5:19 AM, "Ivan Herman" <ivan@w3.org> wrote:
>> "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 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). 

>(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?). 

> 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.

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(μ(x)) occurs in sk(SG) or in
rdfV-Minus.

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 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?
 
> 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.

> 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

-- 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.

Received on Tuesday, 9 March 2010 15:55:40 UTC