Potential text for time-permitting features in F&R

This is to discharge my action at 

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 

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


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.


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 
   + OWL dialects, including OWL DL
   + RDF Schema
   + RIF rule sets

~~Property paths~~


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 


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


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.


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


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.


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 - 

~~Query language syntax~~


Certain limitations of the SPARQL/Query 1.0 language syntax cause 
unnecessary barriers for learning and using SPARQL.


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


Received on Thursday, 25 June 2009 03:09:13 UTC