- From: Bijan Parsia <bparsia@cs.manchester.ac.uk>
- Date: Fri, 13 Mar 2009 17:36:07 +0000
- 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 UTC