Re: [TF-ENT] Agenda 24th Feb teleconf

Some responses below

On 2/24/10 4:18 AM, "Axel Polleres" <axel.polleres@deri.org> wrote:
> On 24 Feb 2010, at 06:29, Sandro Hawke wrote:
>> Anyway, the mapping is perhaps orthogonal to the Ent issue, since graphs
>> which merely describe RIF documents don't have any special semantics.
>> For the semantics, yeah, we want rif:imports, as Axel has mentioned.

> One reason why I am still slightly afraid of the RDF/RDF embedding and which
> is a pro for
> simply rif:imports is:
> 
> if you encode rif into triples of the graph at hand, these triples will also
> contribute to 
> the rule based answers/inferences, this would bring us into the same issues as
> OWL has, i.e.
> there'd be suddenly two ways to deal with this:
> (a) simply treating all as RDF (RDF-based semantics, ir "RIF/RDF Full")
> (b) first extracting the rules, and not considering them as part of the graph,
> which includes checking whether the RIF rules indeed form a well-formed
> ruleset, etc. and then use the RDF/OWL combination-semantics as defined in [1]
> (RIF "direct semantics"?)?
> 
> I am not sure whether I want to get into the issues of (a) when we still have
> a lot to sort out for (b) alone, such as
> a reasonable restriction to finite answers for example.

I'm not quite sure what you have in mind for rif:imports here, but if I
understand things correctly the main problem is that we don't have a
straight forward way to refer to a RIF document from  SPARQL query that
wishes to use a RIF entailment regime and this is mostly due to the fact
that RIF defines importing *from* a RIF document *to* an RDF graph, which
would not work for the SPARQL scenario (since we really want something more
like the reverse).  So we would need a different mechanism and there are a
number of ways to do this, but this mostly a problem of reference and not
semantics.

>>>   o Will each rule set be an entailment regime, e.g., the SD says something
>>>     like: myEndpoint sd:EntailmentRegime <http://example.org/myRules.rif>?

I would think that the entailment regime would be comprised of the RIF-RDF
combination consisting of the RIF document (referred to in some way that
also specifies the entailment profile) and the active/scoping graph as well
as the entailment relationship determined by the profile specified.

>>>   o Not all RIF dialects are based on a model-theory (e.g., RIF PRD), so
>>>     they do not come with an entailment relation, but have a procedural
>>>     semantics. Can we still use the procedural semantics to define
>>>     something like an entailment regime?

I don't think (just my $0.02) that we want to support (at least not
initially) any other RIF dialect beyond RIF Core.  It is a quick win, and
anything else becomes very complicated very fast (monotonic, etc..)
 
>>>   o Which RIF profiles should be included? Only RIF Core? Does RIF Core
>>>     coincide with OWL RDF-Based or Direct Semantics? How many profiles are
>>>     there?

I would think we only want to include (safe) RIF-Core.

> The advantage of (strongly safe) RIF Core is that it lends itself
> straightforwardly to the
> idea of defining the entailment regime via the closure (i.e. minimal Herbrand
> model), since 
> it is always finite. For other entailment regimes, restricting to a finite
> answer set is trickier.

Yes.

> I wouldn't be too worried to leave that open... as we did leave open the
> definition of 
> more dialects in RIF. I'd be happy to go with RIF strongly safe Core, RIF Core
> and 
> RIF BLD for a start. (If we find a volunteer to tackle RIF PRD, also fine).

What is the delta between RIF Core and RIF BLD?

>>>   o What effects do the non-monotonic features of some RIF dialects have?
>>>     E.g., RIF PRD and (anticipated) RIF dialects with default negation.
>>>     How does that interact with SPARQL's non-monotonic features?
>>>     This probably affects issue-43: Should entailment-regimes be declared
>>>     over the whole dataset or individual graphs?
>> 
>> Eeeeek, scary stuff.

>> One little concern I have is Condition 4.  I don't see how one can
>> possibly define a finite answer set for RIF.   For example, given the
>> document:
>> 
>>     if p(?n) then p(?n+1).
>>     p(1).
>> 
>> and the query
>> 
>>     p(?x).

The RIF Core safeness criteria are meant to guarantee finiteness.

>> well, I don't think there's any sensible way to limit this to a finite
>> set of answers.  Is there?

Yes, but requiring that the RIF core documents used to form RIF-RDF
combinations are safe.  I think this is the way to address C4.

-- 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 Wednesday, 24 February 2010 15:12:53 UTC