Re: [TF-Ent] RIF Core Entailment section

As Birte said: where is the 'like' button? :-)

Some comments and questions, mixed editorial and more substantial

------

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

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

------

I had real difficulties to parse the third sentence in the first
paragraph of 7.2 (starting with 'However,...') Could you cut into
smaller sentences? In the same paragraph, at the end, it would be good
to add an explicit reference to the strongly safe condition of RIF core.

------

The starting point of my problem is: why do we need (C2) for the RIF-RDF
case?

My understanding on (C2) is that it is necessary in other entailment
regimes because some of the RDFS or OWL consequences were potentially
infinite, eg, due to the existence of infinite axiomatic triples. That
means, formally that we indeed need this if we use an RIF-RDF
combination where the RDF part refers to RDF semantics.

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? Ie, even if we keep to
RIF Core, we have in fact a series of possible entailments... RDF, RDFS,
and OWL Full would probably require essentially the same set (ie,
inclusion of C2), Simple would not. That being said, (C2) would hardly
harm, so it may be a possibility to keep it there even if it is not
necessary...

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

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 guess Herman ter Horst have these, and we could
add them as an informal appendix. We also have something for OWL 2 RL
(Dave Reynolds' document), ie, we could avoid giving separate
definitions for all the combinations...

That would still leave the RIF-OWL DL combination open. Do we want to
have those (some sort of a SWRL thingy?)

------

I am not sure that your additional comment on lists in the description
of (C2) is necessary. Though it is true, the '(a b)' is a syntactic
artefact of Turtle. This should not be part of the normative section
though it may be useful to have a comment somewhere as an informative
thing. And this remark is not specific to the RIF combination, it is
generic to wherever (c2) appears...

------

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

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.

------

I am not sure I fully understand your remark on OWL 2 RL, but that may
simply reflect my missing technical knowledge, sorry about that.

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.

I am more bothered by your reference to RIF BLD. 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...)


Cheers

Ivan

[1] http://www.w3.org/TR/rif-owl-rl/
[2] http://www.w3.org/TR/2009/WD-rif-owl-rl-20091001/#Inconsistency_rules



On 2010-3-7 03:32 , Chimezie Ogbuji wrote:
> http://www.w3.org/2009/sparql/docs/entailment/gen.html#id21744432
> 
> It has been fleshed out and I have added various references.  There are a
> few editorial notes involving the following issues:
> 
> - the 8th condition (C8) of a common-RIF-RDF-interpretation includes the
> set-theoretic semantics of rdfs:subClassOf that are also used by the RDFS
> Entailment regime
> - Embedding a subset of RIF-OWL combinations (OWL 2 RL for instance) as
> extensions to this entailment regime (issues of consistency checking,
> axiomatic triples and rules)
> 
> Are there examples of RIF Core (normatively) safe rulesets / documents that
> use builtins that do not introduce new values into the domain that are
> useful as arguments against the finite restrictions? I started by looking at
> the extant N3 Logic / CWM builtins but none of them jumped out at me except
> the obvious log:semantics, etc.
> 
> A mapping from all the SPARQL builtins to corresponding RIF builtins (beyond
> those in the RIF Datatypes and Built-Ins document) could further close the
> expressive gap between RIF Core and SPARQL.  I think they would all be safe
> (and maybe also strongly safe).
> 
> ----------------------
> Chime (chee-meh) Ogbuji (oh-bu-gee)
> Heart and Vascular Institute (Clinical Investigations)
> Architect / Informatician
> Cleveland Clinic (ogbujic@ccf.org)
> Ph.D. Student Case Western Reserve University
> (chimezie.thomas-ogbuji@case.edu)
> 
> 
> ===================================
> 
> 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