RE: Issue 3 - Trust Mechanisms in OCLC Authority Control Service

Hi Dave

> By the way, how is the refinement and selection of these use 
> cases being
> directed? Is the process aimed at finding practical solutions 
> to specific and
> real application requirements or at building a focused 
> research programme
> informed by broad classes of applications? Either of these is 
> fine but the
> methodology Simile is using isn't clear to me and it affects 
> how peripheral
> folks, like myself, can contribute.

As you probably know, currently we are working on two documents, 
the research drivers document 
http://web.mit.edu/simile/www/documents/researchDrivers/rd.html
and the prototype strawman document
http://web.mit.edu/simile/www/documents/prototypeStrawman/ps.html
so I'm in the process of trying to resolve the outstanding issues on the RD
document
http://web.mit.edu/simile/www/documents/researchDrivers/rd_issues.html
and elicit some additional prototypes for the PS document. 

So I have one general comment on methodology: I think we need to try to be
more constructive in the way we review documents.  Specifically rather than
raising issues it would be better if we proposed additional or replacement
text. I'm not picking on this issue in particular, but I think we will start
to move faster if we can try to do this. 

I think some additional work is needed on the research drivers document,
mainly in sections 3 - motivating problems and 4 - use cases, specifically:

- The motivating problems section:
  + Not sure if this is the right name - proposed technologies?
  + There are probably technologies here that are missing such as
cryptographic signing for trust - I'm open to suggestions.
  + The team is not in agreement on all the issues, e.g. distribution, open
vs closed schemas, etc. Where there is disagreement I have tried to
represent both sides of the argument e.g. section 3.2.4 or section 3.2.8 but
some sections, particularly the latter, need further work as basically the
material is a reworking of email from the list. It would be helpful to get
the people originally responsible for this material involved in rewriting
and clarifying these additions. 

- The use cases section:
  + This section is more problematic. Really the way I would have liked to
have done was to interview the PIs, transcribe those interviews, present the
interviews as primary evidence and then do some analysis. However we have
just jumped to this second stage, so we run increased risk of
misinterpretation. However I don't think it is realistic to revisit the
knowledge capture process for all the use cases, we just have to push on. 
  + Some of the use cases need some further fleshing out, but its harder for
the extended team to do this, really this is soemthing that needs to be done
with the PIs at the PI phone conference. 

In addition, we have the overarching problem that often the solutions we are
talking about haven't been demonstrated. For example there are papers that
discuss how to use the Semantic Web for interoperation between schemas or
supporting a Web of Trust, but I can't download a piece of software that
demonstrates how this would work. In fact, it is not clear in some cases if
software has been written or whether the reports are speculative. 

So on one hand we have these problems (the use cases), then on the other
hand we have a bunch of possible solutions (the proposed technologies). This
is where the prototype document comes in: this document tries to de-risk the
situation, because it recognises 
i) we are not really sure if the technologies work or how difficult they
will be to deploy 
ii) we know what the ideal solution would look like for the use cases, but
we are not sure how feasible it is to solve these problems
iii) some of the problems are big, so we need a way of breaking up the
problems into smaller chunks 
iv) developing prototypes should help refine the use cases, because it will
create shared understanding between the team and the requesters. 
So I've been advocating a prototyping approach because it helps us answer
these questions. Specifically by limiting the scope of prototypes to 3
months, and limiting dependence, the hope is this will help with derisking.
However at a later stage, we will need to move past prototypes to building a
more integrated system. We haven't really discussed the hows and whens of
this yet. 

So my suggestions for contribution would be
i) look through section 3 of the RD document and propose additional or
replacement text where necessary.

ii) based on section 3 and section 4 of the RD document, review the PS
document. I'm happy to receive either additional or replacement text for
existing prototype activities or proposals for new activities, particularly
if there is something that seems relevant based on the RD document but is
missing.

So in the case of this issue, if you think there is something missing from
section 3 in the RD document please suggest it, I think the importance of
this for the use case needs to come from MacKenzie, but if you can turn this
issue into a prototype activity then that would be very useful?

Does that help?

Dr Mark H. Butler
Research Scientist                HP Labs Bristol
mark-h_butler@hp.com
Internet: http://www-uk.hpl.hp.com/people/marbut/

Received on Tuesday, 27 May 2003 12:20:18 UTC