Re: Personal observations of working group style and process

Simon,

I don't think I fully responded to your actual question.  (Rushing though too 
many emails this morning...)

Your example looks fine, illustrates the approach, and provides a basis for 
evaluating a simple solution.  Except that it makes reference to protocol and 
format specifics.  I could frame a simple PAQ solution in terms of that example 
(roughly, what I put in the wiki), but would try to avoid reference to a 
specific format at this time, as that potentially narrows the scope.

The part following your example "We would then adapt the solution when we find 
..." is very much what I'm proposing.  (Where, in extremis, "adapt" might mean 
"redesign", but I suspect there's enough experience in the group to avoid that.)

Another way to think about this might be to start by specifying those things we 
collectively agree are pretty much bound to be part of any solution.  (e.g. I 
can't imagine that we could usefully define provenance PAQ that does not use 
simple web retrieval as a common case.)  If there are elements for which we do 
not find rapid consensus, don't include them, unless they are really needed to 
implement even a tiny case.

#g
--


Graham Klyne wrote:
> 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:37:44 UTC