[CCGT] Use Case Repository draft plan

[Craig Lee]

All,

After discussing this on the Community Council call today, here's the draft 
plan I wrote up
and also the mock-up web page that I showed at the town hall meeting to 
stimulate
discussion and comments.  The notion of a matrix of attributes was 
something that
stuck in my head early-on but is really one of the last things we'd want to do.
The most important thing is just to capture the most basic info about all 
use cases,
that is to say, just the attribute keywords describing a use 
case.  Different presentations
of the use case information can be worked on later as we gain experience 
with what
really works for most people.

Two additional issues we could note:

1) Selection of wiki that has proper methods for managing information 
hierarchy, etc. (not flat!)

2) Recording audit trails for use cases, i.e., if a use case is augmented 
later with more
info, keep a list of who did what.

--Craig
-------------- next part --------------

GGF Use Case Repository Project
Contact: Craig Lee, lee at aero.org

Goals:

1) Make GGF Use Cases easy to find on the GGF Web Site.

2) Take a phased development approach where the simpliest steps are
   taken first to get the fundamental capabilities in place first with
   a minimum amount of extra work.  More advanced capabilities,
   requiring significantly more work, can be added later if it becomes
   apparent that they are worth the effort.

3) When the initial capability is on-line, get the GGF community to
   start populating it with use cases.

4) Get feedback from the GGF and SDO communities on the usefulness of
   such web-based use case repositories.


Possible Concepts, Ideas, and Capabilities:

Use Cases with attributes.
  Use Cases, as collected at this time, will have varying formats
  but each use case will be associated with a set of key-value attributes.
  This set of attributes will be fixed but there will be a "KeywordList" attribute
  where the use case author can list any number of keywords as appropriate.

Page of links with attribute/keyword matrix.
  Each use case title is a link to the individual use case where all
  attributes and text can be found.  Matrix can be sorted by clicking
  on the column heading.  A set of common attributes could be
  pre-defined but each use case could define their own keywords.  When
  a matrix page is displayed, some common attributes could always be
  displayed but the user might be able to specify additional keywords
  that are used to determine which use cases are listed in the matrix.

Use a Wiki.
  Wikis allows users to read, write, and delete content on the wiki site.
  Group officers should have authority to manage use cases on the wiki.

Search engine capability.
  Add a keyword search engine to the wiki.  This is just a little
  window where the usual text string can be entered along with a
  "Search" or "Go" button.  A page with a ranked list of links
  is returned.

Keep track of hits on each use case.
  Hit count is just another use case attribute.
  Top 10 Use Cases -- Overall based on just hit count.
  Top 10 Use Cases in a specific area.
    Just the use cases that have a specific attribute, e.g., scheduling,
    workflow, etc., are ranked according to their hit count.

Keyword frequency list.
  On a separate page, list all keywords that appear across all use
  cases along with the number of use cases in which they appear.  This
  list could be alphabetical such that users can see which keywords
  already exist, promoting uniformity where appropriate.  This list
  could also be listed in order of frequency, i.e., the number of use
  cases in which the keyword appears.  This could be useful for
  determining which areas are considered to be the most important.

Have a column for institution/authors of use cases.
  Institution and AuthorList should be two pre-defined common attributes
  that all use case must have.  This gives much needed recognition to
  the people that invest the time to write-up use cases.

MyUseCases.
  A user may want to save a set of use cases as defined by their
  specified attribute list that they can come back to on different
  sessions with the GGF web site.

Database of Use Cases.
  An SQL database of use cases could be set-up where users could
  pose SQL queries against attributes of interest.

Data mining.
  Depending on the number and richness of use case details, data mining
  of use cases could be done.

Meta use cases and composite use cases.
  Some use cases may actually be representative of a class of use cases.
  Some use cases may actually involve a set of other use cases.  As we
  gain experience with the use case web site, these meta and composite
  use cases may become apparent.

Use the major classes of use cases to impose structure on the collection.
  As the GGF Use Cases grow, some structure will probably have to be
  imposed on the collection to make it more accessible and
  understandable.  How exactly this structure is defined remains to be
  seen but presumably it would be built around the attributes and
  keywords.

Other concepts, ideas, and capabilities are possible and can be
  suggested.


Developmental Plan:
The steps in this plan are in a rough order of implementation.
At each step, we can evaluate whether we need to take the next step.

1) Stand up a wiki so users can post their own use cases.
   This is very important for getting EGR and other groups on-board
   quickly and really using the web site.  Adding a use case to the
   wiki should be just adding a link to the use case document.
   Initially we will just have a single list of use case links.

   A.) It would probably be best if the use cases were in separate
   documents but, in some cases, the use cases will be collected into
   larger documents, perhaps even GGF documents.  If the use case link
   can point to a specific location within a document, that would be
   great.  If not, then we will have to settle for pointing to the
   containing document as a whole, or the larger document will have to
   be broken into separate use case documents.

   B.) Initially the wiki will completely open, i.e., anybody could
   add, modify or delete use cases.  We may, however, want to limit
   write-access to group officers, i.e., chairs, secretaries, editors,
   etc.  This will probably require account names and passwords.
   Possible a wiki master could manage creating new accounts (mostly
   for group officers).

   C.) Given the free-form nature of a wiki, we will have to rely
   somewhat on convention and user etiquette to make sure that use
   case links are posted in the right place, etc.

   D.) While the Use Case Submission form and Use Case Matrices
   discussed below have distinct merits, the flexible, user-driven
   linking and organization of content on a wiki may have benefits
   for using Use Cases that we just can't foresee right now.

2) Add a search engine capability to the wiki.
   This will a simple keyword search where the user can type in a
   search string and hit the "Go" button.  Presumably a canned basic
   search engine can be added to the wiki, or perhaps such a basic
   search engine is part of the wiki toolkit.  This will return a
   ranked list of links to use cases that can then be investigated.

3) Add a hit counter for each use case document.
   This should be easy to do.  Hit counters can be displayed in a
   variety of ways, e.g., on the use case page itself, with the list
   of use case links, etc.

This will be, I think, the easiest and most fundamental capability we
can stand up so people can start doing something useful.  In the
longer run, however, it might be useful to add some structure to the
use cases.  One of the things that makes the wiki so easy to stand-up
and start using is that it imposes essentially no structure on the web
content or how people use it -- in this case, use case documents.

Hence, to make GGF uses case document even more useful and to enable
important insights into groups of use cases, we could define a minimal
set of common attributes that all uses cases must have.

4) Draft Attribute List:
   Use Case Title
   Institution
   AuthorList -- list of author names
   Date Submitted
   GGF Area submitting use case
   GGF Group submitting use case
   HitCount -- initialized to zero when use case submitted
   Grid Technology KeywordList -- list of author-defined keywords relating to specific
     grid computing topics, e.g., scheduling, workflow, security, etc.
   Application Domain KeywordList -- list of author-defined keywords relating to the
     application domain, e.g., weather, physics, finance, etc.

The keyword lists are very important since it allows the author to
clearly identify the concepts that are central to the use case.  When
a search engine is examining a use case document, it is essentially
doing just string matching -- it doesn't really understand the
semantics of the nature language in the document.  Hence, search
engine results can return hits that have low value with regards to
what the user was looking for.  A keyword list would be a simple
mechanism for finding those use cases that are most relevant to the
user.

We could suggest a list of common keywords that will probably recur in
many use cases, but this is less critical since this will emerge from
the use cases.  We may, however, want to encourage a little uniformity
where appropriate so we don't wind up with multiple keywords that are
different but essentially mean the same thing.  Currently two keyword
lists are proposed; one for grid technology topics and the other for
application domains.  These could be collapsed into one keyword list
for simplicity but this would then conflate keywords from the two
different groups.

5) Use Case Submission Form.
   As part of the wiki, we could have a Use Case Submission Form based
   on the attribute list.  This form could ensure that all fields are
   filled-in, including a URL to the use case document.  Submitted use
   cases would then become part of the GGF Use Case Repository and
   would appear on lists and could be searched with the search engine.

6) Keyword Frequency List.
   If all use cases have a keyword list, it would be easy to compile a
   keyword frequency list that could be displayed on a separate page.
   This list could be alphabetical such that users can see which
   keywords already exist, promoting uniformity where appropriate.
   This list could also be listed in order of frequency, i.e., the
   number of use cases in which the keyword appears.  This could be
   useful for determining which areas are considered to be the most
   important.

7) Use attributes and keywords to build Use Case Matrices.
   While the attributes and keywords could be used via the search engine,
   they could also be used to build Use Case Matrices.  This is a convenient
   way to present the information for human consumption.

   A.) A use case matrix could have Use Case Title in the left column
   (which is a link to the use case document itself, with several
   columns of attributes, and then several columns of keywords with
   bullets denoting whether that use case had that keyword.  Initially
   the attributes and keyword columns would be pre-defined and not
   sorted in any particular order.

   B.) Allow the user to sort the matrix by clicking on a column heading.
   This is a handy way of rearranging the matrix so the use cases of most
   interest to the user are together at the top.

   C.) Rather than having a pre-defined, static set of attribute and
   keyword columns, allow the user to select the attributes and
   keywords that defines the matrix.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GGF_Use_Case_dummy_page.ppt
Type: application/octet-stream
Size: 144384 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/ccgt/attachments/20050712/3753e72f/attachment.obj