Re: [Pragmas] Pragmas as an extensibility point?

Seaborne, Andy wrote:
> 
>> -----Original Message-----
>> From: public-rdf-dawg-request@w3.org [mailto:public-rdf-dawg-request@w3.org]
>> On Behalf Of Lee Feigenbaum
>> Sent: 10 April 2009 06:54
>> To: SPARQL Working Group
>> Subject: [Pragmas] Pragmas as an extensibility point?
>>
>> The main extensibility point for SPARQL that we've considered so far is
>> service description. Standardizing service description would give a way
>> for SPARQL clients to determine the capabilities of a SPARQL endpoint
>> and adjust their behavior/expectations accordingly.
>>
>> It would also provide a framework within which the WG and/or community
>> could begin defining URIs for features that some but not all SPARQL
>> endpoints might support. This would hopefully encourage engines to
>> converge on similar implementations of extensions under common URIs, and
>> aid further standardization efforts down the road.
>>
>> I see the pragmas proposed feature (
>> http://www.w3.org/2009/sparql/wiki/Feature:Pragmas ) as another
>> potential extensibility point.
> 
> If we have a form of fixed single syntax extension for undefined (not standardised) additional operations, then I suggest we consider having a general one. This proposal applies to elements of the query and hence can't contain a graph pattern (without reparsing a string?), only apply to a previous one (e.g. you can't write UNION like this - it has 2 patterns and affects the AST).  
> 
> So the "can I write UNION in this extension syntax" is a good test case of the design.
> 
> Maybe INTERSECTION or DIFFERENCE is a better test case.
> 
>> The idea behind a pragma is relatively simple: provide a way for a query
>> to include arbitrary metadata that can affect the operation of the
>> query. "Advice" to the query engine, you could say.
> 
> This is a different use of pragmas - feature page describes something that processor must reject the query if pragma is not understood.  
> 
> Advice pragmas can be hints to the optimizer and don’t affect the functionality. 
> 
>> Pragmas are implemented in Virtuoso in a way that they can pertain to an
>> entire query, a single triple pattern, or a group pattern ({ ... }). Of
>> course, other designs are possible to simplify grammatical changes.
>>
>> We've considered implementing pragmas in the past in Glitter in Open
>> Anzo, but have not yet done so.
>>
>> As I've said in the past, I'm keen to consider standardizing something
>> like 4 features + extensibility points that will encourage convergence
>> around other SPARQL extensions outside this WG's lifetime in lieu of
>> standardizing something like 8 features and leaving the extensibility
>> points as they are today.
>>
>> I also have a bit of a belief (more on this in another post if I get to
>> it), that extension points fall in the category of standardization for
>> which it's more appropriate for the standards group to be on the leading
>> edge of the "feature curve" rather than the trailing edge (vis a vis
>> implementations).
>>
>> I'd like to hear what other WG members feel about pragmas as an
>> extensibility point for SPARQL and if there are any other
>> implementations of them out there.
>>
>> If anyone can speak of practical experience with XQuery's pragmas as
>> well, I'd love to learn about that.
>>
>> Lee
> 
> We seem to have two concepts: single syntax for functional extension and a syntax for decorating a query with advice.  Both can be useful.

Andy, you're right. I didn't notice the distinction. I'm more interested 
- personally - in the latter. That said, it's not my top priority and 
I'm not hearing much advocacy from the rest of the WG, so I'm not 
inclined to spend much time discussing it, beyond having given it the 
light of day via this thread. :-)

> There is also stored procedure like forms - syntax for a call to some custom code.

We have this already for filter functions, at least. Assignment or 
subselects+projected expressions would also give this sort of behavior, 
rihgt?

> The most general form is to allow arbitrary new keywords in the language along with the keywords taking graph patterns and expressions as delimited arguments (to retain a fixed, grammar and not one that is dynamic on the new keyword and unparsable without knowledge of the keyword).

EricP drew this up for me on a whiteboard a few weeks ago; The engineer 
in me likes it, but I don't think it's a smart idea for the language.

Lee

Received on Tuesday, 14 April 2009 18:09:18 UTC