- From: Ivan Herman <ivan@w3.org>
- Date: Thu, 25 Jun 2009 15:23:40 +0200
- To: Birte Glimm <birte.glimm@comlab.ox.ac.uk>
- CC: SPARQL Working Group <public-rdf-dawg@w3.org>
- Message-ID: <4A437A5C.8020409@w3.org>
Birte, I think you are right, technically, but that might raise some unnecessary questions from the community both the direct and the rdf based semantics are not explicitly addressed (even if the rdf based semantics turns out to be just the same as the current one, but that has to be said explicitly somewhere). B.t.w., the same could be said about RDF Schema, does it need a different query semantics? I am not sure... Ie, I would rather say: [[[ [...] Time-permitting, the SPARQL WG will use the existing framework to define the semantics of SPARQL queries for one or more of these entailment frameworks: + OWL 2 with both Direct and RDF Based Semantics, including OWL 2 profiles + RDF Schema + RIF rule sets ]]] Another issue I have is with RIF Rule sets, (I would leave Axel to say that): I would have thought that only RIF Core and RIF BLD dialects are really o.k. with SPARQL. I do not believe that RIF PLD would be a reasonable candidate... Ivan Birte Glimm wrote: > Lee, > thanks for the work. I would suggest to rephrase OWL dialects into > profiles because that is the official name used in the OWL 2 spec (I > guess that is what you mean by dialects) and I would like to mention > direct semantics here because the RDF semantics of OWL does not really > need a different entailment regime as I understand it, e.g.: > > [...] Time-permitting, the SPARQL WG will use the existing framework > to define the semantics of SPARQL queries for one or more of these > entailment frameworks: > + OWL 2 with Direct Semantics including OWL 2 profiles > + RDF Schema > + RIF rule sets > > Birte > > 2009/6/25 Lee Feigenbaum <lee@thefigtrees.net>: >> This is to discharge my action at >> http://www.w3.org/2009/sparql/track/actions/49 >> >> The goal here is to have enough text that explains what the time permitting >> features are in a way that: >> >> 1) is comprehensive enough to help us build out phase II charter >> 2) will be re-usable / extendable in future versions of the F&R document >> >> To this end, I've tried to do a "Motivation" and brief "Description" for >> each. >> >> Please comment on this, _especially_ if you are not comfortable with any of >> this for the FPWD. We are _not_ going to spend time on this specific text on >> Tuesday before deciding to publish a first public working draft unless there >> are concerns that we have not managed to work out between now and then on >> the mailing list. >> >> Kjetil or Alex, can you please work this into the editor's draft? >> >> Also - please note that we may need to refine the description of common >> functions that is a time-permitting function before publishing the phase ii >> charter, as per ISSUE-2 (http://www.w3.org/2009/sparql/tracker/issues/2). We >> can do this following publication of FPWD of F&R. >> >> >> ~~BGP extensions for entailment regimes~~ >> >> -Motivation- >> >> Many software systems that support entailment regimes such as OWL dialects >> and RDF Schema extend the semantics of SPARQL Basic Graph Pattern matching >> to apply to entailments other than simple entailment. The formal semantics >> of these SPARQL/Query extensions are not standardized, and query writers >> cannot currently be guaranteed interoperable behavior when working with >> multiple query engines that extend SPARQL with the same entailment regime.. >> >> -Description- >> >> SPARQL/Query 1.0 defines a mechanism to adapt SPARQL to entailment regimes >> beyond simple entailment by providing necessary conditions on re-defining >> the meaning of SPARQL Basic Graph Pattern matching. Time-permitting, the >> SPARQL WG will use the existing framework to define the semantics of SPARQL >> queries for one or more of these entailment frameworks: >> + OWL dialects, including OWL DL >> + RDF Schema >> + RIF rule sets >> >> >> ~~Property paths~~ >> >> -Motivation- >> >> Many classes of query over RDF graphs require searching data structures that >> are hierarchical and involve arbitrary-length paths through the graphs. >> Examples include: >> >> * Retrieving all the elements of an RDF collection (structured as a linked >> list) >> * Retrieve all of the names of people linked to me transitively via the >> ex:mother and ex:father relationships (i.e. all my known ancestors) >> * What are all of the direct and indirect superclasses of a given >> owl:Class? >> >> -Description- >> >> SPARQL/Query 1.0 can express queries over fixed-length paths within RDF >> graphs. SPARQL/Query 1.0 can also express queries over arbitrary but >> bounded-length paths via repeated UNION constructs. SPARQL/Query 1.0 cannot >> express queries that require traversing hierarchical structures via >> unbounded, arbitrary-length paths. >> >> Time-permitting, the SPARQL Working Group will define the syntax and >> semantics of property paths, a mechanism for expressing arbitrary-length >> paths of predicates within SPARQL triple patterns. >> >> >> ~~Basic Federated Query~~ >> >> -Motivation- >> >> SPARQL is a concise query language to retrieve and join information from >> multiple RDF graphs via a single query. In many cases, the different RDF >> graphs are stored behind distinct SPARQL endpoints. >> >> -Description- >> >> Federated query is the ability to take a query and provide solutions based >> on information from many different sources. It is a hard problem in its most >> general form and is the subject of continuing (and continuous) research. A >> building block is the ability to have one query be able to issue a query on >> another SPARQL endpoint during query execution. >> >> Time-permitting, the SPARQL Working Group will define the syntax and >> semantics for handling a basic class of federated queries in which the >> SPARQL endpoints to use in executing portions of the query are explicitly >> given by the query author. >> >> >> ~~Commonly Used SPARQL Functions~~ >> >> -Motivation- >> >> Many SPARQL implementations support functions beyond those required by the >> SPARQL/Query 1.0 specification. There is little to no interoperability >> between the names and semantics of these functions for common tasks such as >> string manipulation. >> >> -Description- >> >> Time-permitting, the SPARQL WG will define URIs and semantics for a set of >> functions commonly supported by existing SPARQL implementations. >> >> See Working Group issue: ISSUE-2 - >> http://www.w3.org/2009/sparql/tracker/issues/2 >> >> >> ~~Query language syntax~~ >> >> -Motivation- >> >> Certain limitations of the SPARQL/Query 1.0 language syntax cause >> unnecessary barriers for learning and using SPARQL. >> >> -Description- >> >> Time-permitting, the SPARQL Working Group will consider extending >> SPARQL/Query's syntax to include: >> + Commas between variables and expressions within a SELECT list >> + IN and BETWEEN operators to abbreviate disjunction and comparisons within >> FILTER expressions >> >> >> Lee >> >> > > > -- Ivan Herman, W3C Semantic Web Activity Lead Home: http://www.w3.org/People/Ivan/ mobile: +31-641044153 PGP Key: http://www.ivan-herman.net/pgpkey.html FOAF: http://www.ivan-herman.net/foaf.rdf
Received on Thursday, 25 June 2009 13:24:11 UTC