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

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 03:25:05 UTC