- From: Lee Feigenbaum <lee@thefigtrees.net>
- Date: Wed, 24 Jun 2009 23:08:31 -0400
- To: SPARQL Working Group <public-rdf-dawg@w3.org>
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
Received on Thursday, 25 June 2009 03:09:13 UTC