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

Re: [TF-Ent] RIF Core Entailment section

From: Birte Glimm <birte.glimm@comlab.ox.ac.uk>
Date: Mon, 8 Mar 2010 15:41:37 +0000
Message-ID: <492f2b0b1003080741x3c25dcb1rd318449619ff251d@mail.gmail.com>
To: Chimezie Ogbuji <ogbujic@ccf.org>
Cc: SPARQL Working Group WG <public-rdf-dawg@w3.org>, Ivan Herman <ivan@w3.org>, Axel Polleres <axel.polleres@deri.org>, Sandro Hawke <sandro@w3.org>
Chime,
here are my small editorial comments:

Is the generic RIF URI sufficient or do we need more specific URIs,
e.g., http://www.w3.org/ns/entailment/RIF-RDF-Core or even
http://www.w3.org/ns/entailment/RIF-RDF-Strongly-Safe-Core?

Should we not allow graphs that don't have any spraql-rif:usesRuleset? E.g.:
Legal Graphs: Any legal RDF graph in which each statement with the
predicate sparql-rif:usesRuleset has as object a URI that refers to a
strongly safe RIF Core document. In that case it would just boil down
to simple entailment I would think.

What's the full URL for sparql-rif? Maybe we have to reserve a special
URI for this?

I suggest rephrasing:
Inconsistency: As with the RDF entailment regime, any legal RDF graph
is always *RIF-RDF* consistent and no inconsistency handling is
required.

In the definition of possible solutions, should we not say "the
strongly safe RIF core document*s* referenced from SG."? As I
understand it there could be several references rule sets. And maybe
add "referenced from SG via the sparql-rif:usesRuleset predicate"?
Just to make it even clearer.

I have an example (see Section 2.3) that uses "a" instead of
"rdf:type", but for the vocabulary of the graph that counts as
rdf:type and I point that out when I discuss how the answers are
derived and point to the Turtle document section that also explicitly
says that such abbreviations are to be read as their expanded forms. I
don't repeat this comment for all regimes since it is already clear
from the Turtle document and it might not be necessary to explicitly
say it again for the RIF regime.

In C1, I would also say strongly safe and not just safe because that's
what was used in the legal graphs section.

The editorial note following the main definition of the ent. regime is
not clear to me. The following suggestion won't really clarify it, but
might still be useful. I wouldn't call it C8 because in the referenced
definition it is just 8. and I would add a hyperlink for
common-RIF-RDF interpretation as further up in the text.

In the first example, in line (1) shouldn't <> be [] to denote a blank node?

Can we replace the ehr prefix with the ex prefix? Otherwise we should
either explicitly define the prefix or add it to the preliminaries
section, where we define a couple of prefixes and say that we assume
that such definitions are implicitly present in all graphs and
queries.

Similarly for the time predicate.

I am not sure I really understand the last editorial note about RDFS/OWL.

Birte

On 7 March 2010 02:32, Chimezie Ogbuji <ogbujic@ccf.org> wrote:
> http://www.w3.org/2009/sparql/docs/entailment/gen.html#id21744432
>
> It has been fleshed out and I have added various references.  There are a
> few editorial notes involving the following issues:
>
> - the 8th condition (C8) of a common-RIF-RDF-interpretation includes the
> set-theoretic semantics of rdfs:subClassOf that are also used by the RDFS
> Entailment regime
> - Embedding a subset of RIF-OWL combinations (OWL 2 RL for instance) as
> extensions to this entailment regime (issues of consistency checking,
> axiomatic triples and rules)
>
> Are there examples of RIF Core (normatively) safe rulesets / documents that
> use builtins that do not introduce new values into the domain that are
> useful as arguments against the finite restrictions? I started by looking at
> the extant N3 Logic / CWM builtins but none of them jumped out at me except
> the obvious log:semantics, etc.
>
> A mapping from all the SPARQL builtins to corresponding RIF builtins (beyond
> those in the RIF Datatypes and Built-Ins document) could further close the
> expressive gap between RIF Core and SPARQL.  I think they would all be safe
> (and maybe also strongly safe).
>
> ----------------------
> Chime (chee-meh) Ogbuji (oh-bu-gee)
> Heart and Vascular Institute (Clinical Investigations)
> Architect / Informatician
> Cleveland Clinic (ogbujic@ccf.org)
> Ph.D. Student Case Western Reserve University
> (chimezie.thomas-ogbuji@case.edu)
>
>
> ===================================
>
> 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.
>
>



-- 
Dr. Birte Glimm, Room 306
Computing Laboratory
Parks Road
Oxford
OX1 3QD
United Kingdom
+44 (0)1865 283529
Received on Monday, 8 March 2010 15:42:11 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:41 GMT