Re: [TF-Ent] RIF Core Entailment section

Birte, my response is below

On 3/8/10 10:41 AM, "Birte Glimm" <birte.glimm@comlab.ox.ac.uk> wrote:
> 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?

Are you talking about the base URI to use for the RIF document reference
predicate?
 
> 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.

I think you are right, we don't need to explicitly exclude graphs that don't
have the reference, since the other entailment regimes would automatically
apply. 
 
> What's the full URL for sparql-rif? Maybe we have to reserve a special
> URI for this?

I didn't have one in mind at the time and hoped others had stronger opinions
on a good base URI to use.
 
> 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.

How about: "As with the RDF entailment regime, any legal RDF graph (by
itself) is RIF-RDF-satisfiable, no explicit inconsistency handling is
required."

Since RIF doesn't have any notion of inconsistency in the same sense as in
the RDFS semantics and satisfiability is only defined with respect to a
combination, so it is the RIF document that could effect satisfiability /
consistency not the SG by itself.
 
> 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.

Ok.
 
> 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.

Ok
 
> 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.

Ok, I'll add the reference and refer to it as 8
 
> In the first example, in line (1) shouldn't <> be [] to denote a blank node?

I was using the empty URI reference to emphasize that the usesRuleset
statement is made about the containing document, rather than an arbitrary
blank node, but since the semantics of the predicate doesn't care about the
subject it shouldn't  make a difference.
 
> 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.

I'll revert to the ex prefix

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

A SG could theoretically refer to a safe RIF Core document that included an

Import(<t1> <p1>) statement where <t1> points to an OWL 2 RL or OWL 2 DL
document and the OWL DL profile, or an RDFS graph and the RDFS import
profile.  There are two issues there:  First, we would need (for proper due
diligence) to ensure the semantics of the answers match those of the
existing OWL2-related entailment regimes in the document.  Also, some of the
Informative embedding mechanics for imported RDFS and OWL2 RL address the
SPARQL extension constraints but it is not clear if they go about it in a
way that is inconsistent with the restrictions given in the existing OWL 2
RL / RDFS entailment regimes.  And finally, it is not clear how much the
strongly safe requirement prohibits the embedding mechanism.  These are all
informative mechanisms, so it is probably a moot point, but if we want to
support scenarios where RIF-RDF combinations are interpreted using
embeddings involving OWL then we need to reconcile this with the existing
restrictions. 
 
> Birte

-- 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 Monday, 8 March 2010 16:45:38 UTC