Re: Potential text for time-permitting features in F&R

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