- From: Birte Glimm <birte.glimm@comlab.ox.ac.uk>
- Date: Thu, 25 Jun 2009 12:32:36 +0100
- To: SPARQL Working Group <public-rdf-dawg@w3.org>
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 > > -- Birte Glimm, Room 306 Computing Laboratory Parks Road Oxford OX1 3QD United Kingdom +44 (0)1865 283529
Received on Thursday, 25 June 2009 11:38:50 UTC