RE: BOF at WWW2008 : SPARQL Futures



> -----Original Message-----
> From: Lee Feigenbaum [mailto:figtree@gmail.com] On Behalf Of Lee Feigenbaum
> Sent: 24 April 2008 16:33
> To: Axel Polleres
> Cc: Seaborne, Andy; public-sparql-dev@w3.org
> Subject: Re: BOF at WWW2008 : SPARQL Futures
>
> Axel Polleres wrote:
> >
> > Seaborne, Andy wrote:
> >> Hi all,
> >>
> >> For those at WWW2008, or nearby, we can get a room for a BOF ("Birds
> >> of a Feather") meeting on SPARQL Futures including the question of
> >> what, if anything, a "SPARQL2" (1.1?) might cover.
> >>
> >> Location: 201B, level2
> >> Time:     16:30 Wednesday (23rd)
> >>
> >>         See you there
> >>         Andy
> >>
> >
> > :-(
> >  not there. any tangible outcomes to report? anywhere to place input?
>
> :-( from me too.
>
> It seems that there is a public record of the BOF here:
>
> http://www.w3.org/2008/04/23-dawg-minutes.html

>
> Of course, the ESW Wiki remains a good place to document suggested
> SPARQL extensions (which in turn often are suggested work areas for
> SPARQL2):
>
> http://esw.w3.org/topic/SPARQL/Extensions

>
> > We basically would have to throw in the following proposals for SPARQL2:
> > - propose marriage with XQuery [1] (that might be outside SPARQL itself,
> > since it affects both SPARQL and XQuery)
> > - using sparql as a view-definition language [2,3]
> > - a proper syntax for aggregates and vuilt-ins in the construct part
> >  (our proposal is documented in [2])
>
> Offhand I'm not sure if/which of these are covered on the ESW Wiki or
> not. I encourage you (and anyone else) to add to the Wiki as
> appropriate, and to discuss potential extensions on this list.
>
> Lee

Notes on the SPARQL BOF WWW2008

Thanks to Eric who captured the discussion:
http://www.w3.org/2008/04/23-dawg-minutes.html


Compatibility with the existing specification was seen as very important.

Here are main features discussed that I noted (it's not an exhaustive list of everything mentioned):

* Update

Some form of update capability in the style SPARQL/Query.  The most common motivation is data manipulation capability by the data owner/publisher.  There are several proposals that take the SPARQL-style and add update capability.

* Expressions in SELECT clause

The ability to have expressions, not just variables, in the SELECT clause of a query.  In exising SPARQL it is only possible to return RDF terms that exist in the graph data being queried, not introduce new terms.  This is coupled to subqueries because it allows assignment of expressions in a way that allows the newly calculated term to be used in pattern matching.

* Aggregation and grouping

Counting, and other aggregation operations. The requirement for grouping

* Subquery

SELECT expressions as a new kind of pattern type producing an intermediate table that can be joined/unioned with other patterns.  Related to aggregation.

* Assignment

Subquery with expressions in SELECT can be used for assignment during pattern matching, it is not convenient nor clear.  An explicit form (whether just syntactic sugar or the underlying primitive for expressions in SELECT) would work better for CONSTRUCT queries.

* Negation

Negation in some form is a frequent application writer request.  Often, testing (c.f. FILTERs) for thje absence of a triple or pattern.

* Free text search

A standard way to express free text searches.  Such searches can be generative, in that they cause a number of possible solutions, or restrictively, like a FILTER.

* Property Paths

SPARQL can only express fixed length paths through the graph.  Property paths both make this easier to express but might also express

So rdf:type with subclasses might be: { ?x rdf:type/rdf:subClassOf* ?t }

* Reasoning control

The ability, in standard way, to control the amount of inference being used to answer the query.  This might include having different levels of inference in different parts of the graph pattern (especially no inference).

Received on Saturday, 17 May 2008 20:30:54 UTC