Re: Solicitation of feedback

On Mon, 2010-07-19 at 10:26 -0400, Chimezie Ogbuji wrote:
> Hello.
> 
> In the W3C DAWG, we recently published an updated working draft of the
> SPARQL 1.1 Entailment Regimes.  I understand the RIF WG is closing soon and
> was hoping to get some input regarding the RIF entailment regime (section 7
> RIF Core Entailment) in an official capacity before hand (if it is still
> feasible).

We will have time for this, yes.   We have one person committed to
reviewing, and we'll try to get some discussion going.

> In particular we were hoping for input in the following areas indicated in
> editor's notes:
> 
> 7.1 Referencing a RIF Core document
> 
> "The namespace and URI used for rif:imports is still under discussion within
> the group" 
> 
> We are currently re-using the rif namespace for this predicate and have not
> resolved whether this is appropriate given that we restrict usage to only
> the http://www.w3.org/ns/entailment/Simple profile in forming RIF-RDF
> combinations for the regime and the concern in making such a predicate too
> specific to SPARQL.

Speaking just for myself at the moment, I find it unacceptable for
SPARQL to do this kind of subsetting (regardless of namespace).  I'm
waiting to see what other RIF folks say, and of course it's possible I'm
misunderstanding the situation.  It seems to me SPARQL must simply
delegate to RIF, and not try to profile/subset RIF.   We can do a
version of import that allows a parameter for the entailment regime, and
it's best to not label or restrict the dialect.

Actually, in general, I'd expect the delegation to be to the data -- if
the data uses OWL, then OWL inference is to be done; if the data uses
RIF (import), then RIF inference is to be done, etc.   I know that's not
sufficiently precise for some applications (it doesn't distinguish OWL
direct vs rdf-based semantics, but the aim of OWL it eventually erase
that distinction anyway), but I'm worried that in specifying the precise
case we obstruct (one of) the major intended deployment mode(s).

> Also, would the forthcoming RIF in RDF specification be a more appropriate
> approach than the current import mechanism by allowing the RIF combination
> to be formed directly from any RIF expressed as RDF in the scoping graph -
> rather than by explicit inclusion as we currently do?
> 
> 7.2 (Simple) RIF Core Entailment Regime
> 
> "It is unclear whether safe RIF-Core rules used to form combinations for
> this entailment regime guarantee uniqueness (up to RDF graph equivalence) on
> answer sets [...] Without strongly safe restrictions, there may be
> interoperability issues ... However, strong safety restrictions are only
> defined in the informative sections of the RIF-Core specification"
> 
> Can you give any background into why the strong safety characteristics are
> only an informative part of the specification that might help in informing
> conditions for preventing trivial infinite answers as appropriate for the
> RIF regime if the use of the strong safety criteria is not appropriate for
> this?

I'm going to have to let someone else answer this, or take some time to
swap this back in/figure this out, sorry.

    -- Sandro

> Thanks in advance
> 
> 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 Tuesday, 20 July 2010 12:54:18 UTC