Re: RDF Data Access Working Group : first working draft of SPARQL

At 22:26 18/10/04 +0100, Seaborne, Andy wrote:
>>Yes indeed!  I case of uncertainty, I'd advocate the former.  It's 
>>generally easier to add missing features than to remove superfluous ones, 
>>I think.
>
>My observation is that many people think the same ... until it comes to 
>the doing it early bit!  The production of the working draft was 
>fascinating - everybody was keen to "publish whatever we had" - make it a 
>lightweight thing - until they came to read it (notes: this proves people 
>never read things beforehand - like for F2F meetings :-) .  Then each 
>person had "a few extras and improvements" and they were all different! 
>Each on its own was no big deal - together thay made for extensive revisions.
>
>Your right about minimal - its just there's differences in what's 
>minimal.  The usual (unspoken) driver at the moment is minimizing 
>implementation work (a very slippery slope IMHO) and the companion 
>preserving existing investements ("my way works, why change?" except 
>someone else has a different worable solution!!!).  It's never said like 
>that but behaviours suggest this.

This is true.  I myself am guilty of this.  But I do recognize that many of 
the things I mentioned in my comments are really considerations for future 
work.

Some touchstones I sometimes use are:

- does the proposed minimum in some sense close off any possibility that 
I'd like to see included?   Does it allow me to add my feature as a private 
extension without breaking the core - will software with my private 
extension still honour the minimum core semantics properly?

(Corollory:  it may be better to include a well-considered, simple 
extension mechanism than a single additional feature.  Extensions can be 
standardized later.)

- does the desired extra feature really need to be interoperable?  For 
example, I mentioned that one of my proposals could be implemented by local 
query rewriting:  this suggests quite strongly that the extension does not 
*need* to be interoperable.

- does the desired extra feature really need to be interoperable at 
Internet scale?  It may be that there are small communities who can agree 
bilaterally or multilaterally to deploy some extension.  But if that 
extension needs to be  recognized by entities who cannot reasonably have 
private agreements in order to be useful, then there's a stronger case for 
standardization.

Maybe I'm just stating the obvious here.  And if everyone agrees that a 
feature is useful, there may be a case for including it anyway.  Many of my 
suggestions were offered in the latter spirit.  In short, I don't think 
that SPARQL is seriously restricted in utility if none of my suggested 
additions are included:  I mention them (early) for consideration, no more.

Minimizing implementation work is good, but I suppose a variation of 
someone's (Einstein?) famous comment is applicable:  implementation should 
be as simple as possible, but no simpler.  Clearly, SPARQL in particular 
has to tread a fine line between implementation complexity and operational 
efficiency.  At this stage, it's probably better to focus on features that 
impact gross efficiency (query size limits, etc.) than features that expand 
expressivity/capability.

#g


------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact

Received on Tuesday, 19 October 2004 10:28:15 UTC