- From: Chimezie Ogbuji <ogbujic@ccf.org>
- Date: Tue, 20 Jul 2010 21:44:01 -0400
- To: "Gregory Williams" <greg@evilfunhouse.com>, "Sandro Hawke" <sandro@w3.org>
- cc: "Birte Glimm" <birte.glimm@comlab.ox.ac.uk>, "SPARQL Working Group" <public-rdf-dawg@w3.org>
Comments inline below On 7/20/10 5:13 PM, "Gregory Williams" <greg@evilfunhouse.com> wrote: > I've always considered it a feature that an endpoint could use entailment on > the underlying data and the user would use the same query syntax. I'd be very > hesitant about a syntax that requires the user to specify an entailment regime > to use, especially if the system only supports one entailment regime and will > throw an error if you request others. I don't think the user has to specify an entailment regime, but they should be able to and there should be some order of precedence that determines which is used (in the same way we do with datasets). It seems okay for the server to throw an error if an unsupported entailment regime is requested. > I don't want to be in the position of > trying to submit a query by hand and having to guess the supported entailment > repeatedly or having to download the service description and pick through it > to figure out what entailment regime the endpoint supports. See above. -- 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 Wednesday, 21 July 2010 01:44:46 UTC