Re: [TF-Ent] RIF Core Entailment section

Chime,
I deleted what was clear and commented on what needed clarification below.

BTW, I am also working on the doc to get the C2 definition changed to
what we agreed to and I also make it clearer how errors are mapped to
errors of the SPARQL protocol. I don't think that'll cause any
problems since I only touch the non-RIF sections apart from the
Illegal handling handling bit where I also changed the RIF entry to
say more explicitly what syntax error means in terms of SPARQL
protocol errors.

On 8 March 2010 16:44, Chimezie Ogbuji <ogbujic@ccf.org> wrote:
> 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?

No, I mean the URI given to the entailment regime, which is in the
second row of the table for each of the regimes. This URI is meant to
be used in the service descriptions and uniquely determines the regime
that is being used. At the moment the RIF-RDF Core regime uses
http://www.w3.org/ns/entailment/RIF, which is pretty generic and if we
add other RIF regimes (e.g., RIF BLD), then we cannot also use the URI
for that regimes.

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

Ok, I've that on the agenda for the teleconf, so lets see.

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

Fine with me.

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

see my other email (I removed this also from the RDF regime definition
and it is now discussed in Sec 2.3, which explains C2)

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

Ah, sorry, I didn't even know that the empty URI is legal. My lack of
knowledge ;-)

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

Thanks for the extra explanation. I think I get the point now.

Birte

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



-- 
Dr. Birte Glimm, Room 306
Computing Laboratory
Parks Road
Oxford
OX1 3QD
United Kingdom
+44 (0)1865 283529

Received on Monday, 8 March 2010 17:44:17 UTC