GGF Use Case Repository Project Contact: Craig Lee, lee@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.