Re: Personal observations of working group style and process

Simon,

Your question helped me to recognize a slight ambiguity in my position.

But to address your direct question, then yes I'd argue for a complete solution 
for an easy case, which we also expect to be a common case.  You'll notice that 
I ducked the mention of "tiny case", because I feel that could imply a very 
specific solution.

The ambiguity in my position was that the reference to "agile" possibly implies 
defining a solution for a "tiny case", as you suggest.  What I really wish to 
target is a "tiny solution" to cover a range of easy cases.  My intuition here 
is that rather than starting our work independently from web architecture 
considerations, we can be guided by them (the Web being the most highly scaled 
distributed system ever), and then use our scenarios to uncover any shortcomings 
in those solutions.  (This applies mainly to PAQ;  the provenance *model* needs 
to be squarely based on scenario requirements, but I'd still suggest an approach 
of starting with a simple core that can cover common cases, then see how it can 
be developed to cope with more complex requirements.)

#g
--

Simon Miles wrote:
> Graham,
> 
> I realise this is a matter for the WG chairs, but your arguments seem
> to affect what the access and query task force does for the F2F
> meeting, and understanding concretely what you mean might help clarify
> how to resolve the technical differences.
> 
> If I understand correctly, in the current ('waterfall') approach we
> try to establish agreed principles which cover all cases and gradually
> build up a specification, for example "the thing you ask the
> provenance of may be mutable", "there can be multiple sources of
> provenance data regarding a single thing" etc.
> 
> In an agile approach, we would give a complete solution to a tiny case
> using existing standards, then adapt the solution to cover more cases.
> So we might start with:
>   "A webpage downloaded from HTTP URI X has provenance HTTP URI P,
> which when dereferenced returns an OPMV/Turtle file. The OPMV graph
> includes an artifact labelled opm:pname=X, i.e. the graph says
> something about X's provenance. P is included as link somewhere on the
> webpage in a manner which implies it is for the page's provenance."
> We would then adapt the solution when we find cases where X is
> something mutable, there are multiple providers of data on X's
> provenance, we want software not people to follow the link to the
> provenance, etc.
> 
> Is that what you were arguing for/against?
> 
> I am not taking a position, just trying to understand better, as I
> have not been involved in a standardisation process before.
> 
> Thanks,
> Simon
> 
> On 20 June 2011 11:13, Graham Klyne <graham.klyne@zoo.ox.ac.uk> wrote:
>> All,
>>
>> I have repeatedly noticed that my position on various issues seems to be out of
>> step with that of other active WG members.  I have found this is slightly
>> surprising, as I don't see any fundamental respect in which our goals and aims
>> are different.  It's more a matter of style and approach.
>>
>> I thought it might be worth surfacing how I think this affects our discussions.
>>  I must make it very clear that what I write here is not in any way critical of
>> any other people's approach, just trying to understand our differences.  I
>> particular, I fully support the chairs' desire and approach to address the
>> issues in terms of concrete small pieces on which we can (or should be able to)
>> make progress.
>>
>> In responding to Luc's recent comments about the proposals for access and query,
>> I realized that what I'm proposing as a broad approach looks very like an Agile
>> Methods style of working.  By contrast, the groups approach seems more like a
>> waterfall style:  define the entire problem space, then work on the designs for
>> solutions.  But this is an exercise in standards creation, not software
>> development, so it's interesting to consider if this distinction is applicable.
>>  On reflection, and considering my past experience in standards work, I find my
>> personal view is that an agile mindset is actually more relevant to standards
>> creation than it is to software development.
>>
>> So what do I mean by "Agile" here?  I mean a process that proceeds in multiple
>> incremental cycles, delivering complete end-to-end solutions in small
>> increments, with reflection and review of each such deliverable.  In the context
>> of what we do, I'd like to identify a simplest possible solution that deals with
>> a majority (or significant minority) of requirements, document that, review it
>> to identify errors and omissions, and iterate.
>>
>> What I perceive the group currently trying to do is construct language in order
>> to define the complete problem space.  This is to my mind more of a "waterfall"
>> approach, which IMO is leading to a "bikeshedding" effect
>> [http://en.wikipedia.org/wiki/Parkinson's_Law_of_Triviality], in which we
>> discuss details of word meanings rather than grasp the main problems (no less
>> myself than any others).
>>
>> We have agreed to be driven by user scenarios, which is a Good Thing, but I
>> think something is missing in that process: prioritization.  We have agreed some
>> scenarios, but what we have not done is highlighted some simple features in
>> those scenarios that would, if implemented, have the greatest beneficial impact
>> on users who want to capture and use provenance information.  For my proposals,
>> I have done this implicitly by assuming what I perceive to be a common style of
>> web interaction, focusing on small changes that augment existing practices.  I
>> recognize this not the same thing as prioritization of user desiderata, but in
>> the absence of real user input it's the best I can think of.  (And I do not
>> count the scenarios as real user input here.)
>>
>> I hate to articulate a problem without at least attempting a solution.  So
>> here's what I'm thinking:
>>
>> If we can quickly pull together the simplest possible set of specification
>> drafts that we can possibly imagine as addressing at least some of our goals, we
>> can publish them and solicit feedback.  That way, we stand a chance of learning
>> what we're missing that other people really want.  By keeping the drafts really
>> simple, we minimize the risk of describing something that no user really wants
>> (and in the same stroke, we maximize the chance of their being read and actually
>> getting feedback).  Then iterate.
>>
>> ...
>>
>> In conclusion, I would suggest a possible goal for the F2F might be to identify
>> a *minimal* set of technical requirements upon which we can agree to focus our
>> efforts make progress.
>>
>> #g
>>
>>
>>
>> ______________________________________________________________________
>> This email has been scanned by the MessageLabs Email Security System.
>> For more information please visit http://www.messagelabs.com/email
>> ______________________________________________________________________
>>
> 
> 
>

Received on Thursday, 23 June 2011 10:18:48 UTC