Availability for publications, links and licenses in ODL #63
Replies: 7 comments 12 replies
-
|
The current list of known-values for the status of a loan are:
The same list for the status of a copy contains:
None of them feel like a proper solution for this problem. |
Beta Was this translation helpful? Give feedback.
-
|
Im not sure if it was captured in your articulation of the use cases but an
example of a title being no longer available in a collection is that it was
one of many titles in a subscribed-to collection that is replaced with
another title. This scenario covers subscriptions to content that the
library gets from a subscription service but the library is not selecting
individual titles - the library is getting access to the titles as part of
a general subscription to a vendor collection.
…On Wed, Mar 15, 2023 at 12:16 PM Hadrien Gardeur ***@***.***> wrote:
In ODL, a number of stakeholders have the requirement to convey the status
of a publication or a specific copy acquired by a library.
Among those use-cases we could list:
- Open-access or public domain titles that are removed from
distribution
- Books that get removed for legal reasons
- Copies bought by mistake by a library, for which they're issued a
refund
- Copies tied to a publication with a problematic file, where a refund
is issues instead of replacing the file
The concept of a "status" is not completely foreign to ODL, but it doesn't
really cover these use cases:
- each loan has a status as defined in
https://readium.org/lcp-specs/releases/lsd/latest.html#23-status-of-a-license
- each copy/license acquired by a library also has a status, which is
strictly conveyed in the License Info Document:
https://drafts.opds.io/odl-1.0#4-license-info-document
Among the question that should be tackled:
- Should we extend the value listed in
https://drafts.opds.io/odl-1.0#4-license-info-document ?
- Is there a requirement for additional information in addition to a
status? For example, with a refund, do we need a specific reason why the
copy was refunded?
- How can we express this info in an ODL feed directly?
- Should we use the same field/values for the status of a publication?
How should we convey/transmit this information for a publication?
cc @pbrantley <https://github.com/pbrantley> @jce1028
<https://github.com/jce1028> @jonathangreen
<https://github.com/jonathangreen>
—
Reply to this email directly, view it on GitHub
<#63>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABIE7W3NQWESI4C6DYY7YQDW4HTMPANCNFSM6AAAAAAV4CATTA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
--
Regards,
James English
www.linkedin.com/in/jamesenglish
|
Beta Was this translation helpful? Give feedback.
-
|
So a specific Use case is at the publication level vs license level since we deal with publications that are part of a collection or provider integration
|
Beta Was this translation helpful? Give feedback.
-
|
Our use case is for harvesting a collection from another service so we can republish those items into a combined catalog of items from various distributors or collections provided to the client app. |
Beta Was this translation helpful? Give feedback.
-
|
Going back to this discussion, I think we'll hit a wall if we try to cover every single reason why something gets removed through the use of status values. Here's my preferred approach:
This could look like that: "removed": {
"reason": "https://example.com/reason/refund",
"detail": "This publication was refunded due to a faulty EPUB that doesn't meet accessibility criteria"
} We could define a list of well-known reasons through a registry but this would also allow catalog providers to define their own reasons using a URL. We might also consider adding a specific time/date for this removal. |
Beta Was this translation helpful? Give feedback.
-
|
Since naming things is usually the most difficult topic, here are some thoughts and background info :
|
Beta Was this translation helpful? Give feedback.
-
|
I've also collected internal feedback at De Marque (since we use ODL between a number of our products) based on this proposal and this is what people had to say:
Going back to the first example in this thread, it would look like that: "unavailable": {
"reason": "https://example.com/reason/refund",
"detail": "This publication was refunded due to a faulty EPUB that doesn't meet accessibility criteria",
"updated": "2023-11-21T11:32:11+02:00"
} |
Beta Was this translation helpful? Give feedback.
-
|
As a follow-up to our call this week, here's an updated example: "availability": {
"state": false,
"reason": "https://example.com/reason/refund",
"detail": "This publication was refunded due to a faulty EPUB that doesn't meet accessibility criteria",
"updated": "2023-11-21T11:32:11+02:00"
} [Update] Here are some notes from our call:
|
Beta Was this translation helpful? Give feedback.
-
|
Looking at our current schema, there's a potential conflict when using
This wouldn't be a conflict when used in:
|
Beta Was this translation helpful? Give feedback.
-
|
@barmintor suggested that we could lean into this potential conflict rather than avoid it, which would mean:
I think that overall this could be a good approach:
The only part that I have mixed feeling about is the use of an enum of strings/tokens where some values could be unknown/undefined in the context of the availability of a publication/license: If we go back to our initial examples: Example 1: the whole publication has been removed "publications": [
{
"metadata": {
"identifier": "urn:uuid:92ff26c8-55e0-4e86-89fe-62c73ca7f704",
"availability": {
"state": "unavailable",
"reason": "https://example.com/subscription/removal",
"detail": "This publication is no longer available in your subscription",
"since": "2023-11-21T11:32:11+02:00"
}
}
"images": [
{
"href": "https://example.com/cover.jpg",
"type": "image/jpeg"
}
]
}
]Example 2: a specific mean of acquiring the publication is no longer available "links": [
{
"href": "https://example.com/download.pdf"
"type": "application/pdf",
"rel": "http://opds-spec.org/acquisition"
"properties": {
"availability": {
"state": "unavailable",
"detail": "PDF is no longer available as a download format for example.com",
"since": "2023-11-21T11:32:11+02:00"
}
}
},
{
"href": "https://example.com/download.epub"
"type": "application/epub+zip",
"rel": "http://opds-spec.org/acquisition"
}
]Example 3: a license in an ODL feed is no longer available "licenses": [
{
"metadata": {
"identifier": "urn:uuid:f7847120-fc6f-11e3-8158-56847afe9799",
"format": "application/epub+zip",
"price": {
"currency": "USD",
"value": 7.99
},
"created": "2022-04-25T12:25:21+02:00",
"terms": {
"checkouts": 30,
"expires": "2024-04-25T12:25:21+02:00",
"concurrency": 10,
"length": 5097600
},
"protection": {
"format": [
"application/vnd.adobe.adept+xml",
"application/vnd.readium.lcp.license.v1.0+json"
],
"devices": 6,
"copy": false,
"print": false,
"tts": false
},
"availability": {
"state": "unavailable",
"reason": "https://example.com/reason/refund",
"detail": "This publication was refunded due to a faulty EPUB that doesn't meet accessibility criteria",
"since": "2023-11-21T11:32:11+02:00"
}
},
"links": [
{
"rel": "http://opds-spec.org/acquisition/borrow",
"href": "https://example.com/get{?id,checkout_id,expires,patron_id,passphrase,hint,hint_url,notification_url}",
"type": "application/vnd.readium.license.status.v1.0+json",
"templated": true
},
{
"rel": "self",
"href": "https://example.com/status/294024",
"type": "application/vnd.odl.info+json"
}
]
}
] |
Beta Was this translation helpful? Give feedback.
-
"link" : [
{
"rel": "http://opds-spec.org/acquisition/availability",
"state": "unavailable",
"reason": {
"id": "https://example.com/reason/refund",
"description": "This publication was refunded due to a faulty EPUB that doesn't meet accessibility criteria",
},
"since": "2023-11-21T11:32:11+02:00"
}
] |
Beta Was this translation helpful? Give feedback.
-
|
I've created a draft PR at #73 It's still missing quite a few things:
For our next call, we really need to focus on:
|
Beta Was this translation helpful? Give feedback.
-
|
For the list of reasons, I'd like to use the opds.io domain with a pattern like that: https://registry.opds.io/reason#XYZ A document with all the proper anchor would be published at that URL and provide a registry of reasons. Here's an initial list of potential reasons:
|
Beta Was this translation helpful? Give feedback.
-
|
During our call @tdilauro suggested that for each reason we should also document:
|
Beta Was this translation helpful? Give feedback.
-
|
I've set up a new repo for all future registries, along with an initial list of values for reasons at https://registry.opds.io/reason It's still missing context, use cases and examples but I'll add them as well in future updates. I'll most likely use this opportunity to document other useful registries for the OPDS family of specifications, including (but not limited to) link relationships and properties. |
Beta Was this translation helpful? Give feedback.
-
|
@HadrienGardeur I've been thinking about some examples of this for publications where an item has been removed from a subscription. In that case, sometimes we may know about the subscription removal in advance. It would be nice to be able to communicate this as part of the For example something like this, assuming the current date is 2023-11-10. This would indicate that the title will be removed from a subscription in 10 days: {
"metadata": {
"@type": "http://schema.org/Book",
"identifier": "urn:uuid:blah",
"availability": {
"state": "unavailable",
"reason": "https://registry.opds.io/reason#removed",
"detail": "This publication is no longer available in your subscription",
"since": "2023-11-20T20:28:13Z"
}
}
}In this case though, I don't think that That would make the updated example look like this: {
"metadata": {
"@type": "http://schema.org/Book",
"identifier": "urn:uuid:blah",
"availability": {
"state": "unavailable",
"reason": "https://registry.opds.io/reason#removed",
"detail": "This publication is no longer available in your subscription",
"start": "2023-11-20T20:28:13Z"
}
}
} |
Beta Was this translation helpful? Give feedback.
-
|
@jonathangreen the current model is focused entirely on the present rather than past or future states. The only info that we currently convey about past/future states is through the presence of The way we've named things and re-used existing elements was very much a balancing act as well, as we can see from discussions on this page. With the current proposal, you could indicate that:
I don't think that the current element can represent future changes completely, this would require a different element IMO. Listing future states also opens a can of worms:
|
Beta Was this translation helpful? Give feedback.
-
What if the |
Beta Was this translation helpful? Give feedback.
-
In ODL, a number of stakeholders have the requirement to convey the status of a publication or a specific copy acquired by a library.
Among those use-cases we could list:
The concept of a "status" is not completely foreign to ODL, but it doesn't really cover these use cases:
Among the question that should be tackled:
cc @pbrantley @jce1028 @jonathangreen
Beta Was this translation helpful? Give feedback.
All reactions