- From: Ivan Herman <ivan@w3.org>
- Date: Wed, 24 Feb 2010 11:23:28 +0100
- 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>
- Message-ID: <4B84FE20.8030209@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: [skip] >> >> 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... [skip] >> >>> 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 -- 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
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Wednesday, 24 February 2010 10:23:45 UTC