Re: [TF-Ent] RIF Core Entailment section

Hi all,
I think slowly I understand the issues. First, I want to clarify how
entailment regimes are chosen or not chosen. At the moment the user
has no say in that. An endpoint declares which entailment it uses and
that's it. If I have an OWL reasoner that supports OWL Direct
Semantics and I also add SPARQL support to it, then I would most
reasonably say in my SD that this SPARQL endpoint uses OWL Direct
Semantics and that applies to any graph and any query that's being
asked. If I have an implementation that can be set-up to do simple,
RDF, and RDFS entailment say, then I can set-up different SPARQL
endpoints, one for each regime or I could pick the most expressive
regime and always use that or ... but it is still one regime per
endpoint and the user has to live with what the endpoint decided to
offer.

I can see this being extended in the future, but so far there is no
mechanism in place that allows users to communicate to endpoints what
they would like to have.

Now, my question is why do we use RDF entailment in combination with
RIF and not just simple entailment+RIF? I thought we would just take
some data and in that data you might find references to a rule set
(possibly with imports) and then you take the data, apply the
referenced rules and you can think of the regime as doing simple
entailment on the extended data/partial closure (whatever you want to
call the data saturated by the rules). I can't see why we need RDF for
that. If you also want RDF, you could just add an RDF rule set that
contains the axiomatic triples (minus the rdf:_n a rdf:Property
axioms, which would anyways not fit into a finite file) as true
statements/ground facts. If you want RDFS, you incl. a rule set that
contains additional RDFS axiomatic triples and a couple of rules that
capture the RDFS inferences.
You could just take the ter Horst rules and put them into RIF. The
only thing I am not sure about is whether that is strongly safe.
This could be mentioned in a note and maybe we could even create such
RIF rule sets and point to them. That way you can have RIF+Simple,
RIF+RDF, RIF+RDFS, RIF+OWL RL al with one definition and users can
actually decide which combinations they want by incl. the relevant
rule set. This will not work for OWL Direct Semantics and I would
expect that OWL RDF-Based Semantics can only be captured by a RIF rule
set that is not strongly safe.

Birte


2010/3/9 Chimezie Ogbuji <ogbujic@ccf.org>:
> 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.
>
>



-- 
Dr. Birte Glimm, Room 306
Computing Laboratory
Parks Road
Oxford
OX1 3QD
United Kingdom
+44 (0)1865 283529

Received on Tuesday, 9 March 2010 16:34:50 UTC