W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > January to March 2010

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

From: Ivan Herman <ivan@w3.org>
Date: Wed, 24 Feb 2010 11:23:28 +0100
Message-ID: <4B84FE20.8030209@w3.org>
To: Axel Polleres <axel.polleres@deri.org>
CC: Sandro Hawke <sandro@w3.org>, Birte Glimm <birte.glimm@comlab.ox.ac.uk>, SPARQL Working Group <public-rdf-dawg@w3.org>
My questions are clearly from someone who has only a cursory knowledge
of this stuff...

On 2010-2-24 10:18 , Axel Polleres 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.

Oops, I never realized that problem I must admit but, well, indeed, this
sounds tricky.

On a procedural level: if rif:imports is only a WG note, is it o.k. to
use that in a Standard (Sandro?). Seeing the dynamics and the span of
the RIF WG, I would have difficulties to believe that it could publish a
rec. Maybe the SPARQL WG would have to publish it separately as a REC? I
do not know...


>>>   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 sure hope so.  When we say "entailment regime" what we really mean is
>> "specification of inference", right?  And PRD has a specification of
>> inference, which is all that actually matters.
> I would hope that we can define the Core/BLD semantics also in a procedural way, 
> via some finitely-bounded  canonical approximation of the minimal Herbrand model... 
> I will sketch that in a separate mail...
>>>   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?
> 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.

What is strongly safe RIF Core?

>> I hope we don't have to say anything about which RIF profiles (dialects)
>> are included.  Certainly we don't want to exclude user extensions.
>> (But, again, I don't understand how users interact with this spec.)  
> 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).

My understanding has always been that the semantics of RDF + RIF
Core/BLD is defined, but I have never seen anything on PRD. I would not
mind if, at least in this round, we would restrict ourselves to BLD/PRD...



Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF   : http://www.ivan-herman.net/foaf.rdf
vCard  : http://www.ivan-herman.net/HermanIvan.vcf

Received on Wednesday, 24 February 2010 10:23:45 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:59 UTC