W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2009

Re: [TF-ENT] RDFS entailment regime proposal

From: Chimezie Ogbuji <ogbujic@ccf.org>
Date: Sat, 26 Sep 2009 01:48:19 -0400
To: "Birte Glimm" <birte.glimm@comlab.ox.ac.uk>, "SPARQL Working Group" <public-rdf-dawg@w3.org>
Message-ID: <C6E32363.CAAB%ogbujic@ccf.org>
On 9/24/09 1:30 PM, "Birte Glimm" <birte.glimm@comlab.ox.ac.uk> wrote:
> whoever is interested in RDFS entailment: I would be very happy about
> comments and suggestions for the RDFS entailment regime as outlined
> in:
> http://wiki.webont.org/page/SPARQL/OWL

Hey Birte.  I have a few comments, focusing mostly on the technical content
rather than style, wording, etc.

> [..] The only additional answers from RDFS compared to RDF are some axiomatic
triples, plus any IRI used as a property will end up as part of an answer to ?p
rdf:type rdf:Property.

The initial language here seems to suggest ruling out answers that, when
substituted into the pattern instance, result in graphs which can be derived
from SG, axiomatic triples, and the application of the RDFS entailment
rules.  Later on, however, the RDFS entailment relation is used in defining
the solution mappings for the query answers.

> There are a view design choices that I have listed at the end of the
> section on RDFS, which could be an alternative to the currently
> proposed way of restricting the answers sets to a finite size. Please
> let me know prefer any of them or have any other suggestions.

> .. if μ(v) is a blank node, then μ(v) occurs in the scoping graph SG

So, is the general intuition here that answers where subject terms are Blank
nodes must "refer" to a priori blank nodes in the SG?

> Ideally,
> a monotonic behavior for queries would be very nice, but that is not
> easy to achieve when solution sequences are possibly infinite without
> restrictions.

Well, isn't monotonic usually a characteristic of an entailment
relationship? In this case it is not the RDFS entailment relationship that
is monotonic (in the sense of the word I'm used to, anyways), but rather
there is a difference in answers based on whether or not pattern
substitutions involve terms in some combination of either the signature of
the SG or the query.

But, how does

ASK { rdf:_1 rdf:type rdf:property }

provide an answer via the entailment regime if the possible solutions for a
BGP under an entailment relationship is defined only WRT the variables in
the query but there are none in this query?

I like the 2nd option amongst the alternative design choices. It requires
that if the user makes the mistake of giving a query that would normally
give infinite answers (the use of patterns that match against axiomatic
triples being one example), they must provide a restriction on the solution
set.  Having no control over the returned answer seems reasonable given the
'unsafe' nature of the query.

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


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 (2008).  
Visit us online at http://www.clevelandclinic.org for
a complete listing of our services, staff and

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 Saturday, 26 September 2009 05:50:12 UTC

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