Support for wishlist

[HadrienGardeur]

For many catalogs where users need to buy/subscribe/borrow content, having native support for a wishlist in OPDS would help users to keep track of what they'd like to a eventually acquire.

In order to implement a wishlist in OPDS 2.0, this proposal introduces two new rel value as well as a new property.

The new rel values would be:

• http://opds-spec.org/wishlist to identify the wishlist itself
• http://opds-spec.org/wishlist/item to identify interactions with a specific wishlist item

The wishlist itself could be discovered either in:

• a feed, listed under links
• or in a user profile, also listed under links

Here's an example of what a wishlist link would look like:

{
 "href": "/wishlist",
 "rel": "http://opds-spec.org/wishlist",
 "type": "application/opds+json" 
}

The wishlist feed itself is a normal OPDS feed that will contain publications and/or groups. It can be paginated and could even provide context-specific search in the wishlist.

To add/remove a publication from the wishlist, we would rely on a link included in each publication object:

{
 "href": "/wishlist/book/12345",
 "rel": "http://opds-spec.org/wishlist/item",
 "properties": { "present": true }
}

Since this is user-specific, this link would strictly show up under two potential conditions:

• in a user-specific feed (for example a bookshelf)
• or when the client authenticates the user to access a publication (see New link-level hint for authentication #43 for more details on how this can be achieved)

To indicate whether an item is already present in the wishlist, the link would include a new present hint in properties where the value is a boolean.

This links would allow two different interactions:

• adding the publication to the wishlist, through a PUT request
• removing the publication from the wishlist, through a DELETE request

In both cases, a successful interaction would return a 204 No Content status code with an empty payload.

I believe that http://opds-spec.org/wishlist could be part of the main specification moving forward (OPDS 2.0+) while the interactions could be covered in a separate document.

Any feedback is of course welcome. cc @leonardr

[HadrienGardeur]

We're currently testing this feature across a rather larger set of libraries and patrons.

One area where we're still hesitating is how we should handle unauthenticated patrons:

• hide the link to add an item to a wishlist from them
• or show a link that will require them to authenticate when they interact

For now we've decided to hide the link but this is not consistent with other features (such as the ability to see a borrow button, even if you're not authenticated).

[leonardr]

Just explicitly saying that I think this makes sense as a low-fi wishlist solution. I can see how the properties can be used to extend it (e.g. allowing the user to write a note or wishlist ranking).

And it sounds like the semantics of present would be defined in a supplemental JSON-LD vocabulary that goes along with the document describing the interactions.