Re: Lee's feature proposal

Seaborne, Andy wrote:
>> (Roughly in this order.)
> 
> I am surprised at prioritisation.  The survey captures WG members sense of priorities by the ranking.  See also below.
> 
>>      * SPARQL/OWL
>>      * Property paths
>>      * Function library
>>      * Basic federated query
>>      * Surface syntax

(I already discussed negation, but wanted to touch on this.)

I put SPARQL/OWL at the top here since, while I think it is a bit too 
risky to consider it a required deliverable, I think that it is likely 
that the WG members who would be spending their most time defining the 
required deliverables would not be a strong overlap with those who would 
work most heavily on defining SPARQL/OWL.

Property paths & basic federated query seem likely to have a much higher 
overlap of people's time.

That said, I fully agree that it is very important for the WG as a whole 
to devote appropriate time to any work products that are to come out of 
the WG. It's just that at the same time I acknowledge that when it comes 
right down to it, it is specific people (and groups of people) that 
'create something out of nothing' to define specifications.

(Not sure if that makes any sense :-)

Function library & surface syntax can sort of go on at their own pace, 
as I see it, so didn't fit neatly into the prioritization.

Let's see, maybe a better way to explain what I was thinking/proposing 
is that I see there being 3 "tracks" of time-permitting deliverables in 
this proposal:

track 1
-------
property paths
basic federated query

track 2
-------
SPARQL/OWL

track 3
-------
function library
surface syntax

The first track extends the query language and probably requires 
significant attention by those WG members most interested and able to 
define syntax & semantics of query language features.

The second track is orthogonal to the core query language, and requires 
significant attention by those WG members most interested and able to 
define how OWL (and other entailments) fit into the SPARQL BGP extension 
mechanism.

The third track affects the core query language, but feels to be like 
smaller 'bites' that can be handled maybe in parallel with other efforts.

And I'll repeat once more for clarity: I'm talking the energy to craft 
initial specifications - for *all* of these features, I expect that 
nothing will be published/delivered without ample review by the entire 
Working Group.

Lee




> 
> 
>>      * group preference
>>      * group energy
>>      * implementation experience
>>      * utility to developers
>>      * utility to end users
>>      * extensibility
>>      * conservatism
> 
>> And in the personage of Bijan Parsia, the
>> SPARQL WG has the expertise and energy necessary to properly specify the
>> SPARQL/OWL basic graph pattern matching extension. SPARQL/OWL received
>> minimal support in the survey, but seemed to have a somewhat warmer
>> reception in the discussion on the April 28 teleconference.
> 
> In my opinion, one of the important aspects of a working group is that the group as a whole devotes time to the consideration of a feature, review of material and preparation of the final concrete deliverables.  Having someone to put energy into a feature is only one side of the equation.
> 
> There was no strawpoll the second time.
> 
> Other people said they would champion other features.
> 
> (This is not directed at Bijan whose energy in this WG I appreciate)
> 
>  Andy

Received on Sunday, 3 May 2009 03:20:51 UTC