Use cases for OPDS and ODL

[HadrienGardeur]

During our kick-off meeting earlier this week, Sameer Verma suggested building a list of well-known and potential use cases for OPDS and ODL.

To facilitate this task, we'll use this Github Discussion and follow-up during our monthly calls.

[HadrienGardeur]

Some of the "classic" use cases for OPDS:

• provide a catalog for a library or a retailer that allows users to browse/search/acquire ebooks and audiobooks
• create a private bookshelf with all the ebooks/audiobooks that you own, usually in the cloud or on a NAS
• expose and harvest content available under an open license

ODL has a main use case:

• harvest content that a library acquired from a distributor
• create new loans based on these acquisitions
• track the status of a given copy acquired from a distributor

[pbrantley]

Fwiw, not just deletions but replacements or substitutions (e.g. errata). My guess is that this is more for OPDS, but there are several ways these could be handled including via workflow. If I remember correctly, at IA we wound up creating a separate delete / replace OPDS catalog. Not elegant but workable.

[HadrienGardeur]

OPDS Distributors is an extension to OPDS that helps use OPDS vs ODL to harvest titles in a collection for redistribution or access via some access control mechanism like DRM or templated URLS. This is for content namely that has permissive use by authorized users.

Do you have any documentation for OPDS Distributors? How is it different from ODL?

One thing missing in OPDS and ODL is a formal mechanism for content removals from collections holdings.

Yeah, this was mentioned by Benjamin Armintor during the call and I agree that there's a use case for this, but mostly for use cases where an OPDS/ODL feed is harvested by a third party.

[jce1028]

@HadrienGardeur The biggest differences between OPDS "distributors" and ODL are:

as I understand it are as follows

1. The absence of a License Object
2. The lack of the License Status Document

Also, it is typically just a crawlable feed that is paged- no group feeds or navigation feeds. 1 caveat - a navigation collection may be used to pub publishers to designate "modules" or publisher-specific collections as with Bibilioboard or FULCRUM .

One "extension" we provided for was templated urls where a token endpoint is defined at the root feed element so that bearer tokens could be requested and acquisition links could be "templated' for bearer token use.

[jce1028]

Fwiw, not just deletions but replacements or substitutions (e.g. errata). My guess is that this is more for OPDS, but there are several ways these could be handled including via workflow. If I remember correctly, at IA we wound up creating a separate delete / replace OPDS catalog. Not elegant but workable.

Does the modified date object in the Publication signal a change for a client to update its metadata? I think replacements or substitutions may be handled by the file host and OPDS publisher. But I may be missing the nuance here. Maybe what is really needed is guidance as to the purpose for some specific data elements in the feed or documenting the expected use?

[HadrienGardeur]

1. The absence of a License Object
2. The lack of the License Status Document

Neither of them are actually required in ODL. You can also include publications that simply contain an "open-access" acquisition link.
How do you actually handle acquisition links in these use cases ?

Also, it is typically just a crawlable feed that is paged- no group feeds or navigation feeds. 1 caveat - a navigation collection may be used to pub publishers to designate "modules" or publisher-specific collections as with Bibilioboard or FULCRUM .

I see and this reminds me of OAI-PMH.
Basically you need a discovery document to list all sub-collections, but how are these collections selected then? Are they automatically selected and crawled by a bot or is this list of sub-collections displayed to a human being?

One "extension" we provided for was templated urls where a token endpoint is defined at the root feed element so that bearer tokens could be requested and acquisition links could be "templated' for bearer token use.

OK, that one is not entirely clear to me. Are you saying that acquisition links require authentication somehow and that this is handled through a Bearer Token?

[pbrantley]

@jce1028 I think a simple modified date field obfuscates the source of the modification. That might be okay in some cases, not in others. A correction in metadata is very different than a target digital object replacement. I don't have a ready response in the trade off of markup simplicity vs functionality -- i.e. how much information to make explicit and let the client be simple ("stupid") vs embedding more logic in the protocol itself.