- From: Christian de Sainte Marie <csma@ilog.fr>
- Date: Mon, 24 Apr 2006 18:08:54 +0200
- To: Dave Reynolds <der@hplb.hpl.hp.com>
- CC: public-rif-wg@w3.org
Dave, Basically, I agree with you, although I believe that, at least some of the requirements cannot be considered without taking the more complete picture into account. However, I am rather reluctant at the idea of committing us to individual requirements before we have a clearer picture of what they mean (including as a set). Indeed, there are limits to how much the implications of a requirement can be analysed without getting into the actual design. But using that discussion to start getting into the design seems a good propery to me: the more concrete discussion helps us (well, at least: me) understand the requirements and issues better; and it helps the WG progress towards its final objective (a technical spec). This being said: +1 to differentiating the discussions about whether a DC is described clearly and unambiguously enough to be useful, from the discussions of the consequences of DCs on the design of the RIF. Christian Dave Reynolds wrote: > > I've been reflecting on why it seems to have taken the bulk of a > telecon to, as yet, fail to agree on a RIF Design Constraint [1] that is > simple, unopposed and mandated by the charter. Given that a > conservative estimate is that we'll end up with >20 constraints > then a rate of less than 1 per week is a little low. > > My concern is that we are trying to over analyse the consequences of > each requirement. A requirement just has to be clear enough that a > reasonable person can look at the final design and see if we've made a > plausible job of addressing it. There are limits to how much the > implications of a requirement can be analysed without getting into the > actual design. > > An analogy ... > My manager once described an accountancy course to me. > The course contrasted the US and UK approach to regulating company > accounts. The US legal approach is to define a set > of practices which must be obeyed (Ai) and a set of practices which > are outlawed (Di), a set of accounts which meets all Ai and omits all > Di is legal. The UK approach is to effectively say something like "the > accounts must be honest and transparent". So if someone invents a new > accounting trick which any reasonable person would regard as a scam but > it is not within any of the defined Di they can get away with it in > the US but not in the UK. The UK definition is measurable but it > relies on people and judgement to interpret it. > > Similarly if a requirement is clearly enough defined that any > reasonable technical observer could tell whether the final RIF design > meets that requirement or not then it is specified well enough. We > need to worry about whether the whole set of requirements reflects a > coherent and sufficient set to lead to a useful outcome. Obviously we > need to think enough about individual requirements to eliminate those > that are not desirable or not mathematically possible, but perhaps we > don't need to pin down every last consequence of them at this stage. > > Or maybe I'm just too much of a scruff. > > Dave > > [1] > http://www.w3.org/2005/rules/wg/wiki/The_RIF_Core_must_be_able_to_accept_RDF_triples_as_data > > > > >
Received on Monday, 24 April 2006 16:07:43 UTC