Re: [UCR] Process comment

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