Re: [ENT] Review comments on the SPARQL 1.1. Entailment regime document

I have committed changes to the ?(Simple) RIF Core Entailment Regime.
Normative references to *strong* safety have been removed from 7.2 and moved
into 7.4.  The entailment regime is now only built on safe RIF documents.
An editor's note has been added regarding the concern about whether answer
sets with uniqueness up to RDF graph equivalence can be guaranteed without a
finite grounding.  It is not clear (from what I can gather from the
literature and in the RIF Core document) whether the safety conditions can
guarantee a unique minimal model (even if they cannot guarantee a finite
grounding), since most documentation on methods for ensuring unique minimal
models are used on languages with negation (which RIF-Core does not have)
and nothing seems to be said about positive, safe Horn clause languages with
built-ins in this regard.

I have also clarified the language of 7.4 to better describe the background
of strong safety and how it addresses *both* unique and finite answer sets
(where the former is required, the latter is not).

[1] http://lists.w3.org/Archives/Public/public-rif-wg/2009Feb/0065.html

On 5/19/10 11:24 PM, "Chimezie Ogbuji" <ogbujic@ccf.org> wrote:

> Birte, thanks for the comments.  I intend to address them (hopefully by the
> end of the night) but there are some principled concerns that I wanted to
> raise ASAP (because I believe they warrant an editorial note) so there is
> enough time to work through the changes we resolved to make with your approval
> prior to publication.
> 
> On 5/18/10 2:43 PM, "Birte Glimm" <birte.glimm@comlab.ox.ac.uk> wrote:
>> .. snip ..
>> "We will only define answers with respect to those RDF graphs that are
>> (simply) satisfiable and ..."
>> Does simply satisfiable here refer to RDF's simple interpretations? I
>> thought that any legal RDF graph has a simple interpretation, i.e., a
>> model under the simple semantics (no extra RDF(S) conditions/axioms
>> apply). .. Snip ..If it is RDF's simple, then that is redundant
>> isn't it?
> 
> Yes, it is meant to be RDF simple entailment, is redundant, and will be
> removed.
>  
>> There are still several places where we seem to enforce RIF strongly
>> safe core documents, which is no longer necessary given the relaxed
>> conditions on extensions to BGP matching.
> 
> This is the part that is problematic for me.  For instance, RDF entailment
> *enforces* finite answers and appeals to the relaxation of the restrictions by
> (essentially) categorizing entailment from BNodes and axiomatic triples as
> 'trivial' (I put trivial in quotes because - as Andy mentioned - the word is
> problematic and often used subjectively as is the case here).
> 
> It seems to me like the same standard is being applied differently and
> justified by a subjective determination of what kind of infiniteness is
> appropriate to rule out.
> 
>> "We will only define answers with respect to those RDF graphs that are
>> (simply) satisfiable and RIF-Simple-entailed by the combination formed
>> from the (skolemized) scoping graph and a referenced, ***strongly safe
>> RIF-Core*** [RIF-Core] document. "
>> URI in the 
>> table:http://www.w3.org/ns/entailment/RIF-RDF-***Strongly-Safe***-Core
> 
> I will change the entailment URI to remove reference to strongly safe.
>  
>> .. snip .. 
>> Is that not the same as saying: Any legal RDF graph with exactly one
>> triples that has rif:imports as a predicate.
> 
> Yes, I will change the wording
> 
>> Furthermore, there
>> should probably be an editorial note saying the the prefix rif of
>> rif:imports is not yet decided and could be changed to something else
>> later on.
> 
> I will add this note.
>  
>> In the query answers part of the table you say:
>> A solution mapping μ is a possible solution ...
>> ... and the ***strongly safe*** RIF core documents referenced from SG
>> via the rif:imports predicate.
>> 
>> That should probably be just solution instead of possible solution
>> because the purpose of that part in the table is to define solutions.
> 
> Ok, I will change that.
> 
>> ..snip.. Ideally, I would just
>> declare this as solutions without messing around, but unfortunately
>> blank nodes and axiomatic triples can introduce infinitely many
>> redundant answers that nobody really wants to see. This infiniteness
>> is quite different than those that you get from recursive rules say.
> 
> I don't think this form of infiniteness is different from those you get from
> recursive rules.  An infinite solution set is an infinite solution set
> regardless of how you come about it, and if the general goal was to allow
> infinite solution sets then we should just remove the restriction altogether
> rather than introducing ambiguity in order to justify removing some forms of
> infiniteness.  Unfortunately, I wasn't able to participate in the F2F to argue
> this point.    
> 
> However, the strong safety restriction in RIF-Core is only informative (even
> in the proposed recommendation and I am curious as to why this is so - Axel?),
> which by itself is a more principled justification for not using it
> normatively in the RIF-Core entailment regime.  So, I will remove (normative)
> references to strong safety but will further emphasize (amongst other things)
> in the informative section the issues of interoperability (discussed as
> justification for safety restrictions) that users of unsafe RIF entailment
> regimes should be aware of.
> 
>> ..snip..constant in question cannot have been in the queried graph. Anyway,
>> long answer with mostly theoretical concerns ;-), but I would prefer
>> to use sk as in the other regimes or, if you don't want that, at least
>> say that sk is defined for any bnode in any BGP.
> 
> I appreciate the long answer, it does help me understand skolemization as it
> relates to how we reduce infiniteness via Bnode.  However, I'm not sure
> exactly where my use of sk differs from the other regimes since I essentially
> copied the text from that of the other regimes.  Can you show me exactly where
> the difference is?
> 
>> 7.1
>> ...  However, for our scenario, the inverse of such a reference is
>> needed and a specific IRI is designated:
>> http://www.w3.org/ns/entailment/RDF-RIF-imports. In the subsequent
>> text, we will refer to this IRI as rif:imports.
>> 
>> Even if I define the prefix rif for http://www.w3.org/ns/entailment/,
>> that wouldn't give me rif:imports.
> 
> I will fix that.
> 
>> An editorial remark would also be
>> good to make clear that the actual URI to which rif expands is not
>> really decided yet.
> 
> I will add this note.
> 
>> You continue:
>> ... Combinations used in this SPARQL entailment regime must be
>> interpreted using the semantics specified in the Simple profile
>> (http://www.w3.org/ns/entailment/Simple) unless the RIF document
>> explicitly imports RDF or OWL using a profile with a higher precedence
>> (as specified in 5.1.1 Specific Profiles of the RIF RDF and OWL
>> Compatibility document)**.** (fullstop missing)
>> 
>> Now, the question is, what actually are the answers/solutions if I do
>> have an import that uses for example the OWL Full profile (I am
>> surprised BTW that RIF uses OWL Full and OWL DL to refer to the
>> semantics and not OWL RDF-Based and OWL Direct Semantics). The ent.
>> reg. document does not really specify that. It always assumes simple
>> semantics as per the table.
> 
> In this case, the graph should be considered not well-formed for the regime.
> I will update the section on legal graphs to rule this scenario out.
> 
>> 7.3
>> ... This entailment regime restricts the legal graphs to only those
>> that refer to strongly safe RIF core documents. ...
>> That is no longer required. We can now allow also not strongly safe
>> RIF core documents,
> 
> Yes, but as I've mentioned before, by that same logic RDF entailment (for
> example) should not include provisions to rule out infiniteness by relying
> only on a subjective interpretation of what is trivial.  If we want to apply
> the standard in the same way, then RDF entailment (and the others) should be
> defined such that infiniteness is *not* ruled and an informative section
> should be added where the conditions that rule them out are placed.
> Otherwise, it is a double standard.
> 
>> but in that case, finiteness is not guaranteed.
>> What the changed condition on extensions to BGP matching requires is
>> that trivial sources of infinite answers should be defined and
>> excluded by the regime. This is deliberately a bit vague,
> 
> Yes, very vague.  So much so, that I wonder about the value of using 'trivial'
> at all.
> 
>> but answers
>> that just return different bnode labels are clearly in this category,
>> e.g., if I have
>> SG:
>> ex:a ex:b ex:c.
>> and query:
>> SELECT ?x WHERE { ?x ex:b ex:c }
>> I do not want to get:
>> _:a1, _:a2, _:a3, ... although _:a1 ex:b ex:c, _:a2 ex:b ex:c, _:a3
>> ex:b ex:c, ... are all entailed by SG. This should also be prevented
>> in the RIF regime, whereas recursive rules might also lead to infinite
>> answers, but such answers are not just trivial infinite answers.
> 
> They may not be trivial (in the subjective sense) but they certainly introduce
> interoperability issues which can be argued to be just as harmful as ambiguity
> due to (unexpected) infiniteness.
> 
>> Sorry that this got longer than intended...
>> Birte
> 
> No, problem.  It is something that needs to be discussed thoroughly.
> 
> -- 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 Thursday, 20 May 2010 21:54:26 UTC