W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > January to March 2009

Re: [sub-select] Some examples and discussion

From: Bijan Parsia <bparsia@cs.manchester.ac.uk>
Date: Fri, 13 Mar 2009 17:36:07 +0000
Message-Id: <2DF5BA25-E734-4E89-A95C-CDEA2CF6C2A8@cs.manchester.ac.uk>
To: SPARQL Working Group <public-rdf-dawg@w3.org>
On 13 Mar 2009, at 17:22, Steve Harris wrote:

> On 13 Mar 2009, at 16:08, Ivan Mikhailov wrote:
>
>> Chimezie,
>>
>>> I don't think I agree that optimization and implementation effort  
>>> (which is
>>> a direct consequence of the complexity introduced by more  
>>> expressive query
>>> forms such as sub-selects) should *not* be a factor.
>>
>> I'd say even more.
>>
>> Optimization and implementation effort must be ignored as decision  
>> factor, "must" in its ultimate, RFC 2119 meaning.
>
> I'm not sure I agree.

I'm sure I don't agree.

> Implementation effort is certainly relevant, there is no point try  
> to specify a feature that not enough people will implement to make  
> it to rec. Optimisation effort is a different matter.

Exactly, "two interoperable implementations" is a standard CR exit  
criterion. I'll go further, I think given a choice between two  
features, one which will be easily implemented widely, soon, at  
production quality, at scale is to be preferred, from a user  
perspective, to a nominally "nicer" (more expressive, more  
intelligible) feature that will only get toy or crappy implementations.

You can't consider users without considering the likely effect on  
implementation.

>> The reason is that language users are much more numerous than  
>> language implementations.

While true, it doesn't mean we can treat implementors as if their  
concerns were irrelevant. Aside from being against the consensus ethos  
of the W3C, it generally leads to suboptimal outcomes for users.

Another way of thinking about it is that someone has to bear the  
implementation cost. Features are not free, even if they are free  
beer, open source. They have opportunity costs if nothing else.

>> A book composer do not pay much attention to the author's comfort  
>> when it conflicts with the comfort of readers.

I don't know what a book composer is, but again that doesn't seem right.

>> A public transport dispatcher would ignore personal wishes from  
>> train crew --- the railway is built not for their needs.

But it has to take them into account. It would lower prices on the  
train to force the crew to work for no pay, but that's not a good idea.

>> We're in similar circumstances.

Definitely not. Or rather "yes we are" but I don't agree with how you  
would handle the other circumstances.

>> IMHO, there's a short list of excuses for excluding a user-friendly  
>> feature from spec:
>
> User-friendliness is a matter of judgement. What one person thinks  
> is clear and obvious will be confusing to another. It depends on  
> background and prior experience as much as anything else.

And "brute" user-friendliness (whatever that might be) can be damaged  
by poor support.

I prefer to represent my own institutions interests as closely as  
possible without generalizing too much. And I prefer to respect other  
institutions interests as express, preferably closely, by their  
representative. I prefer not to have too many general rules about  
whose interests win since, by and large, they can only reasonably work  
when all other things are equal, which they rarely are and even more  
rarely are seen to be.

Cheers,
Bijan.
Received on Friday, 13 March 2009 17:36:44 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:38 GMT