Some Embedding necessary for RIF-Simple - Was Re: [TF-Ent] RIF Core Entailment section

So as I was taking another pass through the Simple RIF Core section, I
noticed a problem that I will need to addressed.  In short, without some
amount of 'embedding', RIF-Simple entailment will behave in a
counter-intiuitive way if there is no correspondence between statements and
frames, rdf:type and #.

Consider the example below

Scoping Graph
-------------
_:a rdf:type _:b
<> rif:imports <emptyRules>

Where emptyRules.rif is an empty document

A SPARQL query such as SELECT ?THING ?CLASS { ?THING a ?CLASS } will return
nothing!  In fact (as I understand it - I'm hoping someone else can confirm
this) *all* queries will return nothing with the current language:

"A solution mapping μ is a?possible solution [...] such that sk(P(BGP)) are
well-formed RDF triples that are RIF-Simple entailed by the?RIF-RDF
combination formed from sk(SG) and the?strongly safe?RIF core documents
referenced from SG via the rif:imports predicate"

As a result of condition 7 for common-RIF-RDF-interpretations <I',I> (where
I' is a RIF-BLD semantic structure and I is a simple interpretation), the
scoping graph is not satisfiable by such an I in a
common-RDF-RDF-interpretation.  In particular IEXT(IS(rdf:type)) is *not*
equal to the set of all pairs (a,?b) in?Dind?×?Dind (since the latter is an
empty set).  This condition, along with others requires this correspondence
in order for an common RIF-RDF-interpretation to be valid.

As a result, the combination will not entail anything and since the answers
are defined with respect to RIF-Simple entailment, there will be no answers.

The mechanisms in section 9.1.3 Embedding Simple Entailment in the
compatibility document provide some tools to address the problem and I'm
inclined to re-use them rather than simply refer to that informative section
since the goal of embedding (to demonstrate how a RIF-compliant translator
without native support for RDF can process RIF-RDF combinations) seems very
different from what we are doing here as I understand it.

My suggested solution is to form the combination differently:

SG' = sk(SG)
<merge(R,?R_{simple-core},tr(SG')), SG'>

Where merge is the same function that is defined towards the end of 9 of the
appendix and tr is the same injective function described in the appendix as
well.  The difference between how tr is used in 9.1.3 and how it is used
here is that nothing will need to be done with BNodes (since they will be
replaced with new IRIs by the time the function is evaluated over SG').

R is the same strongly, safe RIF Core document referenced from SG.
R_{simple-core} is essentially the same ruleset as R_{Simple} (from 9.1.3)
except for the exclusion of the rule involving ## (which is not allowed in
the RIF Core syntax anyways).  So it is:

Forall??x??y (?x[rdf:type ->??y]?:-??x #??y)
Forall??x??y (?x #??y?:-??x[rdf:type ->??y])

This effectively ensures that condition 7 is met.  So, for our example,

merge(R,?R_{simple-core},tr(sk(SG))) becomes

Forall??x??y (?x[rdf:type ->??y]?:-??x #??y)
Forall??x??y (?x #??y?:-??x[rdf:type ->??y])
<skolem_iri_1>[rdf:type -> <skolem_iri_2>
<skolem_iri_1> # <skolem_iri_2>

And without the issue of the conditions regarding the correspondence between
frames and statements, the subgraph characteristics of simple entailment
hold, sk(P({?THING rdf:type ?CLASS})) *will* be RIF-simple entailed, and
answers would be provided.

Any thoughts before I try to incorporate this?

-- 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 Friday, 12 March 2010 20:11:22 UTC