Change Policy

Anyone may add new Proposed Use Cases at any time.

The modification or removal of a Confirmed Use Cases may be requested by a Stakeholder on http://code.google.com/p/openpub/issues/list and discussed on the mailing list. Similarly, Stakeholders may create issues and initiate discussion on the confirmation of any Proposed Use Case. Consensus will need to be documented before any modification, deletion, or additions are made to the Confirmed Use Cases list.

Please continue the numbering but do not edit any existing numbers.

Confirmed Use Cases

1. Self-publishers should be able to create OPDS Catalogs of their titles (even if they only have one) (P6)
2. Traditional publishers should be able to create OPDS Catalogs of all of their electronically-available frontlist and backlist titles (P7)
3. Traditional libraries should be able to create OPDS Catalogs of their available electronic holdings (P8)
4. Digital libraries should be able to create OPDS Catalogs of their available electronic holdings (P9)

5. Library management systems should be able to create OPDS Catalogs of their electronic publications (P10)

6. Digital distribution service vendors should be able to create OPDS Catalogs of the electronic publications they are able to provide (P11)
7. A journal publisher should be able to create OPDS Catalogs of their available electronic issues (P12)
8. Aggregators should be able to combine and enrich OPDS Catalogs before republishing (P13)
9. Catalog publishers should be able to provide authenticated, authorized, or public Catalogs (P15)

10. Catalog publishers should be able to provide metadata-rich Catalogs (P17)
11. Catalog publishers should be able to provide minimal, metadata-poor Catalogs (P18)
12. Discovery portals should be able to crawl the web for OPDS Catalogs (P19)
13. Discovery portals should be able to index complete OPDS Catalogs in order to provide multi-Catalog search & browsing interfaces (P20)
14. Acquisition portals should be able to allow readers to acquire free titles via OPDS Catalogs (download) (P21)
15. Acquisition portals should be able to allow readers to acquire titles with payment via OPDS Catalogs (vend) (P22)
16. Acquisition portals should be able to allow readers to acquire titles for a limited period via OPDS Catalogs (lend) (P23)
17. Reading systems should be able to allow readers to browse OPDS Catalogs (P26)

18. Resource-limited reading systems should be able to allow readers to browse OPDS Catalogs (P28)

19. Catalog publishers should be able to provide links to reviews for entries in a catalog (P30)

20. Reading systems should be able to filter possible acquisition links for compatibility with the reading system (P31)

21. Catalog publishers should be able to provide the total number of entries found in sub-catalogs. (P32)

22. A Reading system should be able to acquire/update their entire personal Catalog from a Library management system (P35)

23. Catalogs should be able to support multiple, alternative acquisition scenarios for each publication (P38)
24. Catalogs should be able to support affiliate systems (P39)

25. Catalog consumers should be able to handle changes in Catalogs due to additions, updates, or deletions (P40)

Proposed Use Cases

1. Users should be able to carry around an OPDS catalog of publications they are or may be interested in. Their personal catalog should contain information on where individual publications might be located, specifically distinguishing on-disk, local-network, local-server, and global-internet catalogs (each of which may be an aggregator of multiple catalogs). {SJ}

2. An OPDS catalog should be amenable to automatic updating, particularly with availability information (again, with 'availability' captured in the catalog in many facets, since a catalog user may have access to the catalog but to only a subset of possible shelves). {SJ}

3. An OPDS catalog should be able to interface with available interlibrary loan processes (for both digital and physical publications) to help derive the ''shortest path" between a user and a copy of a work. Some capture of likelihood / frequency of availability and 'distance' in time and money to access is important. {SJ}

4. An OPDS catalog should support certain common search functions, particularly for each of the above three use cases. Which is to say it should contain any metadata needed for such searches. {SJ}

5. An OPDS catalog should be compressible. It should support revision and enhancement of a fixed-size catalog with access to changing quantity, quality information. A device with limited storage space should be able to maintain over time the 'most useful' set of information in its OPDS catalog for a set of interesting works. So if each work has 100k of associated metadata, a catalog of 100,000 titles restricted to 10MB of space should include sufficient meta-information about importance, interest, &c to identify how much information to store. {SJ}

6. Self-publishers should be able to create OPDS Catalogs of their titles (even if they only have one) {KHF}
7. Traditional publishers should be able to create OPDS Catalogs of all of their electronically-available frontlist and backlist titles {KHF}
8. Traditional libraries should be able to create OPDS Catalogs of their available electronic holdings {KHF}
9. Digital libraries should be able to create OPDS Catalogs of their available electronic holdings {KHF}
10. Library management systems should be able to create OPDS Catalogs of their electronic publications {KHF}
11. Digital distribution service vendors should be able to create OPDS Catalogs of the electronic publications they are able to provide {KHF}
12. A journal publisher should be able to create OPDS Catalogs of their available electronic issues {KHF}

13. Aggregators should be able to combine and enrich OPDS Catalogs before republishing {KHF}

15. Catalog publishers should be able to provide authenticated, authorized, or public Catalogs

17. Catalog publishers should be able to provide metadata-rich Catalogs {KHF}
18. Catalog publishers should be able to provide minimal, metadata-poor Catalogs {KHF}

19. Discovery portals should be able to crawl the web for OPDS Catalogs {KHF}
20. Discovery portals should be able to index complete OPDS Catalogs in order to provide multi-Catalog search & browsing interfaces {KHF}

21. Acquisition portals should be able to allow readers to acquire free titles via OPDS Catalogs (download) {KHF}
22. Acquisition portals should be able to allow readers to acquire titles with payment via OPDS Catalogs (vend) {KHF}
23. Acquisition portals should be able to allow readers to acquire titles for a limited period via OPDS Catalogs (lend) {KHF}

26. Reading systems should be able to allow readers to browse OPDS Catalogs {KHF}
27. Bandwidth-limited reading systems should be able to allow readers to browse OPDS Catalogs {KHF}
28. Resource-limited reading systems should be able to allow readers to browse OPDS Catalogs {KHF}

29. Catalog publishers should be able to provide price data for entries in a catalog.{TJ}
30. Catalog publishers should be able to provide links to reviews for entries in a catalog {TJ}
31. Reading systems should be able to filter possible acquisition links for compatibility with the reading system.{TJ}
32. Catalog publishers should be able to provide the total number of entries found in sub-catalogs.{TJ}
33. Catalog publishers should be able to describe expected affiliate data (format, url, anything else?){TJ}

34. Magazines/newspapers should be automatically checked and updated when a new version is available {HG}
35. A user should be able to synchronize their bookshelf and automatically download new acquisitions {HG}
36. A user should be able to authenticate for a given catalog {HG}
37. A user should be able to stay authenticated, without using sessions/cookies {HG}

38. Catalogs should be able to support multiple, alternative acquisition scenarios for each publication
39. Catalogs should be able to support affiliate systems

40. Catalog consumers should be able to handle changes in Catalogs due to additions, updates, or deletions

Comment by project member abdela...@gmail.com, Jul 29, 2009

Use cases should be condensed where possible (15-18).

► Sign in to add a comment