Re: Do we need "summaries" of the Use Cases?

I'm a bit concerned about the inclusion of the use cases in the final  
document. While I think the cases are useful, I think that the final  
document should be an analysis of our thoughts on LLD and what needs  
to be incubated, even in areas that are not covered by the use cases.  
The use cases should be a source of ideas, but not the only source.

Therefore, I would rather leave the use cases online. The document  
could summarize what we learned from them, but does not need to  
summarize the cases themselves. (cf. the suggestion that each use case  
be given 3 pages in the document). It is my opinion that the value of  
the use cases is what they teach us about LLD, not the cases qua cases.

Thinking about why we didn't get one or more use cases with a strong  
statement about our need for a library data carrier other than MARC,  
and only one case talking about library legacy data, I have come to  
the conclusion that these topics may be too big for the use case  
methodology. In addition, the use of use cases is not the norm in my  
library experience -- it seems to be oriented to specific applications  
that come out of an IT perspective  (which is what we received). It is  
perhaps for this reason that we did not get a whole picture from our  
use case effort. I think we must give a larger view in our document by  
looking beyond the use cases to other needs.

kc

Quoting Thomas Baker <tbaker@tbaker.de>:

> Dear all,
>
> The final report outline [1] foresees an appendix with
> edited Use Cases, one per page.
>
> I'm wondering if each Use Case should have a one- or
> two-sentence summary describing what it is and how it
> uses (or plans to use) linked data?
>
> For now, these summaries could be added just after the "Owner"
> section and before "Background and Current Practice".  If the
> summaries were short enough, maybe we could even put them into
> the body of the report, where they would take up perhaps one
> and a half pages that people might actually read as opposed
> to forty pages that people are more likely to skim.
>
> I'm even wondering if the summaries could be "transcluded"
> into the outline, but I never quite got my head around how
> that really works (and whether it would be worth the extra
> technical work).
>
> If others think this is a good idea, I'd be willing to pick
> off a few Use Cases as examples.  Writing a summary, I find,
> it is a good way to re-read something carefully.
>
> More generally, we're moving into a phase in which we will
> need to be doing alot more re-reading, and I'm wondering what
> ground rules we should set for making editorial corrections.
> It would require alot of extra email for everyone to ask
> permission of curators before making edits, but I'm guessing
> that in most cases the additional effort would be welcome.
>
> Unless there are objections, I suggest we all feel free to
> make corrections of a minor wordsmithing or editorial nature
> to any document, even "curated" ones, but that after we have
> done so, we should as a courtesy send a note to the authors
> with a link to the "diff" showing our changes (e.g., [2]).
>
> Tom
>
> [1] http://www.w3.org/2005/Incubator/lld/wiki/FinalReportOutline
> [2]  
> http://www.w3.org/2005/Incubator/lld/wiki/index.php?title=ScribeDuty&diff=2668&oldid=2526
>
> --
> Tom Baker <tbaker@tbaker.de>
>
>



-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet

Received on Thursday, 13 January 2011 22:22:26 UTC