CF/CM Use Cases
From OCLC Intranet Wiki
Assumptions and General Discussion of Use Cases
- All use cases are intended to work across all iterations of OCLC platforms for all licensed content products.
- Multiple test cases can, and should, be written for each Use Case.
- With the exception of UC Other-1, the use cases described here are not directly concerned with end-user "Discovery" or "Delivery" activity. Rather, they describe the use of supporting tools (the connector framework, the self configuration manager) by OCLC or library staff to configure an instance of WorldCat Local to enable discovery via external databases (broadcast searching).
[edit]
Section I: Configuration Manager
[edit]
UC Config Manager - 1 Configure (Enable) a Database for Federated Searching
|
[edit] Details | |
| Primary Actors: WorldCat Local customer (librarian) | Supporting Actors: |
| Preconditions: The user has access to the Configuration Manager for the library’s WorldCat Local instance or access for a Group Catalog | Success Guarantee: User can select meta-search targets and save their profiled configuration of targets. |
| Level: | Complexity: |
| Assigned To: | Release: |
| Flow of Events | |
| Main Success Scenario: 1. User logs into Configuration manager and navigates to configuration section for selecting meta-search targets. 2. User is able to easily browse and/or search for configurable targets. 3. User is able to select targets to be searched. 4. User is able to select whether target is searched from WorldCat index or as broadcast search via PazPar2. 5. User is able to supply credentials for the target if they are required. 6. User is able to test the searching of the target from within the Configuration Manager before needing to save their changes. 7. User saves configurations and they take immediate effect. Extensions: | |
|
[edit] Clarifications, Notes, Comments and Questions | |
| NOTE: It should be stated that though these User Cases are being created to help in understanding how to integrate the Connector Framework into OCLC services, this particular use case addresses the entire range of libraries configuring meta-search targets. This means it addresses both targets which OCLC has indexed the meta-data for and targets that must be broadcast searched. NOTE: List of targets must also include the supplier. Many databases are available from (libraries subscribe to them from) more than one supplier/platform. For example, MEDLINE: FirstSearch MEDLINE (WCP) / EBSCO MEDLINE (metadata bucket) / Ovid MEDLINE (federated/Z39.50) / PUBMED (federated/connector). [bad example b/c MEDLINE is already part of XWC?] NOTE: For databases OCLC resells from other vendors there are three possible choices for the user. Take Wilson Select Plus. The choices will be WSP bought from OCLC (current FS sub), WSP indexed into .org but bought from Wilson, broadcast search WSP at WilsonWeb. NOTE: Broadcast targets that are Z39.50 enabled and do not need connectors should still just be choices in the Configuration Manager. The needed configuration should have already been done by someone capable of creating connectors. | |
Is the assumption that a connector will be created as part of the library configuring a new database for fed searching? What about dbs that another customer has already configured? Connector framework only required the first time a customer wants to set up the db for searching?
[edit]
UC Config Manager - 2 Library Staff Creates / Edits a Database Group
|
[edit] Details | |
| Primary Actors: | Supporting Actors: |
| Preconditions: | Success Guarantee: |
| Level: | Complexity: |
| Assigned To: | Release: |
| Flow of Events | |
| Main Success Scenario: Extensions: | |
|
[edit] Clarifications, Notes, Comments and Questions | |
|
- how do they control display order of db groups? Is it default group first, other groups in alpha order – or do we want them to be able to specify display order? (this is on adv search form)
NOTE: Pretty sure we need one more use case on how (and by whom) the FIND-indexed databases get 'enabled' so they appear in the configuration manager target selection section. Is it when someone at OCLC creates a collection description for them? Is that what makes it possible for the Library to add them to a database group? | |
[edit]
UC Config Manager - 3 OCLC Staff Configures New or Edits Existing Z39.50 Federated Search Target Profile (does not require connector) -- SHORT TERM USE CASE
[edit]
UC Config Manager - 4 Library Staff/Technical Person Configures New or Edits Existing Z39.50 Federated Search Target Profile (does not require connector)
|
[edit] Details | |
| Primary Actors: Person with Z39.50 knowledge, does not require development | Supporting Actors: |
| Preconditions: The user has access to the SPOE interface | Success Guarantee: |
| Level: | Complexity: |
| Assigned To: | Release: |
| Flow of Events | |
| Main Success Scenario: 1. User can log in to some place on earth (SPOE) 2. User can inform SPOE they are creating a Z39.50 search target 3. User designates target domain and dbname and credentials as required 4. User inputs all appropriate Bib-1 attributes, supported services and record syntax. 5. User can test search target without saving the configuration profile 6. User can save configuration profile 7. Target configurations can now call Z39.50 configuration profile OR 1. User can log in to SPOE 2. User can easily browse and/or search existing Z39.50 configuration profiles 3. User can call existing configuration profile into edit mode 4. SPOE runs automatic tests against target for supported services, Bib-1 attribute set and record syntaxes supported 5. User can easily accept information returned into the configuration profile User can test search target without saving the configuration profile 6. User can save changes to the existing configuration profile or save as a new configuration profile 7. System archives previous version which can be recalled 8. Targets using this configuration profile must have a controlled manner of switching from previous version to new version (please see NOTE in Use Case 2 above) Extensions: Cannot access SPOE (authentication) Target/database already exists Incomplete Z-attribute config? | |
|
[edit] Clarifications, Notes, Comments and Questions | |
| NOTE: Separate Z39.50 search target definitions will be required for different record syntaxes, e.g. MARC or OPAC, to simplify target selection by library staff This is probably two separate use cases – how are they different? We assume OCLC staff will create initial ones before self-config manager is ready. | |
[edit]
UC Config Manager - 5 Librarian / Technical person Creates Collection Description for a Database
|
[edit] Details | |
| Primary Actors: Library staff or OCLC staff with knowledge database being described | Supporting Actors: |
| Preconditions: The user has access to the Configuration Manager, collection description section | Success Guarantee: User can create Collection Description and it can be associated with one or more Target Service Descriptions |
| Level: | Complexity: |
| Assigned To: | Release: |
| Flow of Events | |
| Main Success Scenario: 1. User can login to Configuration Manager and navigate to collection description configuration section 2. User can choose to create a new collection description 3. User is prompted for necessary collection description meta-data elements 4. User can save collection description 5. Collection description becomes available in a controlled manner to the Configuration Manager target service description for association OR 1. User can login to Configuration Manager and navigate to collection description configuration section 2. User can easily browse and/or search existing collection descriptions 3. User can call existing collection description into edit mode 4. User can save changes to the collection description or save as a new collection description 5. Collection description becomes available in a controlled manner to the Configuration Manager target service description for association Extensions: Cannot access CM/registry (authentication) Collection description already exists (criteria for determining same?) | |
|
[edit] Clarifications, Notes, Comments and Questions | |
| NOTE: Collection descriptions describe what is in a database and are normally independent of the platform the database is presented on. For example MEDLINE has a collection description which can be associated with MEDLINE on FirstSearch, MEDLINE on CSA, etc. | |
[edit]
UC Config Manager - 6 Librarian / Technical Person Configures New Federated Search Target Service Description
|
[edit] Details | |
| Primary Actors: Library staff or OCLC staff with knowledge of target information OR the creator of a connector or Z39.50 configuration profile | Supporting Actors: |
| Preconditions: The user has access to the Configuration Manager, target configuration section | Success Guarantee: |
| Level: | Complexity: |
| Assigned To: | Release: |
| Flow of Events | |
| Main Success Scenario: 1. User can login to Configuration Manager and navigate to target service description configuration section 2. User can choose to create a new target service description 3. User is prompted for to input necessary target meta-data elements including selecting the associated collection description 4. User is prompted to select connector or Z39.50 configuration profile to associate with this target 5. User can test target without saving new target service description 6. User can save target service description 7. Target service description becomes available in a controlled manner to the Configuration Manager target selection section OR 1. User can login to Configuration Manager and navigate to target service description configuration section 2. User can easily browse and/or search existing target service descriptions 3. User can call existing target service description into edit mode 4. User can save changes to the target service description or save as a new target service description 5. Target service description becomes available in a controlled manner to the Configuration Manager target selection section Extensions: Cannot access CM/registry (authentication) Target/database already exists Connector/Z39.50 configuration profile does not exist (which comes first, Connector or Config?) Think that a Collection Description is a required element to save the target service description. | |
|
[edit] Clarifications, Notes, Comments and Questions | |
| NOTE: Will OCLC always approve any new target? I don’t think this is possible since we may not have access to it. Also, are the public and private target configurations. E.g. and institution may want to search a local repository using a connector. Maybe the repository has not access controls so they don’t want it publicly available. Do FIND-indexed databases need target service descriptions? Or just collection descriptions? | |
[edit]
Section II: Connector Framework
[edit]
UC Connectors - 1 Developer Creates a New Connector / Edits Existing Connector
|
[edit] Details | |
| Primary Actors: Developer | Supporting Actors: |
| Preconditions: The user has access to the Connector Framework developer interface | Success Guarantee: Can create and save a new connector or access and edit existing connectors and save. Connector becomes available for use to targets. |
| Level: | Complexity: |
| Assigned To: | Release: |
| Flow of Events | |
| Main Success Scenario: 1. User logs into to developer interface 2. User designates a search destination with any necessary credentials 3. Framework provides list of potential input parameters, e.g. authentication, search indexes, etc. 4. Framework guides user through creation of connector 5. User is able to test connector without saving it 6. User can save connector 7. Target configurations can now call connector OR 1. User logs into developer interface 2. User is able to easily browse and/or search for existing connectors 3. User can call existing connector into edit mode 4. User can have framework repeat analysis of database as in 3 above 5. Framework guides user through possible changes to the connector 6. User can test any changes to connector without saving 7. User can save changes to existing connector or save as new connector 8. System archives previous version which can be recalled 9. Targets using this connector must have a controlled manner of switching from previous version to new version (please see NOTE below) Extensions: Connector already exists and a user is trying to create another new connector for same database CF cannot access the search destination (search destination does not exist) CF cannot access the site (access control) CF cannot build a connector | |
|
[edit] Clarifications, Notes, Comments and Questions | |
| NOTE: It is probably necessary to have a notification system for anyone using a connector to alert to changes and allow them to decide which version to use. Another scenario is OCLC admin type person is alerted and must approve the new version so it starts to be use. NOTE: Open question on who develops the developer interface but agreed this is most likely an OCLC task. NOTE THAT a database on a target might require multiple connectors because of different authentication methods: IP, Athens, username/password, etc – and that the Config Manager needs to surface those different ’flavors’. Hopefully this is just a variable in the connector and the site states which method it is using in the Configuration Manager. Julie raised concern that the actual connector might be different past the authentication piece. Also creator of connector may not be using all the different possible auth methods so could not make this a variable in the connector itself which would then require separate connectors be created for each auth method. | |
[edit]
Section III: Other
[edit]
UC Other - 1 OCLC Software Performs a Federated Search
|
[edit] Details | |
| Primary Actors: OCLC software | Supporting Actors: |
| Preconditions: (specific instance of WCL/FI, database to search is one the WCL/FI instance has rights to) | Success Guarantee: Software can send query to target and receives results which can be understood and rendered in the user interface. |
| Level: | Complexity: |
| Assigned To: | Release: |
| Flow of Events | |
| Main Success Scenario: 1. Software recognized database and knows if it is indexed or federated. 2. If federated the software knows whether connector is needed or not. 3. If no connector needed software sends Z39.50 search to the target 4. If connector is needed software sends Z39.50 to gateway to invoke the specified connector 5. Gateway then sends properly formatted query to database target 6. Each batch of results from Z39.50 search use standard Z39.50 record syntaxes for parsing data to converted into internal format for re-use by WorldCat interface 7. Each batch of results from database target requiring connector are parsed by the Gateway and converted into internal format for re-use by WorldCat interface 8. Software must be aware of total number of results and how many have been returned and capable of asking for another batch of results until all results have been returned. This can be user generated in responding to a visual prompt that more results are available or automatic as the user pages forward the software goes and gets more batches. Extensions: Site unavailable / does not exist Connector/Z39.50 target returns error Results received but unable to parse Timeout reached | |
|
[edit] Clarifications, Notes, Comments and Questions | |
[edit]
Formatting Suggestions
Questions should be added to the "Clarifications, Notes, Comments and Questions" section of the use case. This is a table cell, so there is wiki formatting around it. Number them by starting each with a pound sign.
When responding, insert a line just after the question, and prefix it with a pound sign followed by an asterisk. This will make the response a bullet point under the numbered item, and it will preserve the remaining numbering. (If it's a multi-point response, you can use multiple pound-stars.)
For both questions and responses, after the number/bullet prefix, enter 3 tilde characters, a colon and a space, and then the text. The tildes tell the wiki to show your username, so we can easily track who said what. (The next time you edit, you'll notice that the tildes have been converted.)
Example:
The "Clarifications..." section of a use case has two questions:
====Clarifications, Notes, Comments and Questions==== |- |colspan = "2"| # [[User:User1|User1]]: Question 1 # [[User:User2|User2]]: Question 2 |}
Add a response to Question 1:
====Clarifications, Notes, Comments and Questions==== |- |colspan = "2"| # [[User:User1|User1]]: Question 1 #* ~~~: Response 1 # [[User:User2|User2]]: Question 2 |}
End result of table cell contents:
Followup questions to responses can stay at the same level, since the responses are not numbered. This will avoid multiple levels of indentation. Example:
# [[User:User1|User1]]: Question #* [[User:User2|User2]]: Response #* [[User:User1|User1]]: Followup question #* [[User:User2|User2]]: Followup response # [[User:User1|User1]]: Question 2
