Re: [UCR] Process comment

Christian de Sainte Marie wrote:
> 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.

Agreed.

> 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).

Fair enough. I particularly agree with the need to look at the whole set - 
your separate message concerning Frank & Paula's strawman schedule 
addresses that issue nicely.

Dave

> 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:52:49 UTC