Re: [TF-Ent] RIF Core Entailment section

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.

> The informal advise I got from Sandro and Axel, b.t.w., is to keep away
> from the '#' and '##' notations because it is muddy. Maybe you should
> explicitly use rdf:type in your example...

Ok.

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

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

> 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?
 
> B.t.w., If Sandro's encoding of RIF in RDF is also published, we could
> also refer to it as an alternative to get to rules... It would then be
> just another graph, just like the OWL ontologies.

Sounds good.

> First of all, I understand the reference to rif:error() predicate. The
> note of Dave[1] says, about rif:error():
> 
> [[[
> We translate such rules using a distinguished nullary predicate
> rif:error(). If this predicate is derived then the original RDF graph is
> inconsistent under OWL 2 RL semantics.
> 
> Note: in practice implementers may wish to replace rif:error() with a
> unary predicate which can be used to convey diagnostic information on
> the nature and source of the inconsistency that has been detected.
> ]]] [2]
> 
> which means that we can simply refer to our general mechanism on
> inconsistencies when referring to rif:error(). That seems to be easy.

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

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

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

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 Monday, 8 March 2010 16:00:44 UTC