Skip to content

Latest commit

 

History

History
69 lines (50 loc) · 2.83 KB

OPDS.md

File metadata and controls

69 lines (50 loc) · 2.83 KB

OPDS structure

OPDS generated by this app uses Dublin Core for representing Calibre metadata information.

Since there is no direct correspondence between Calibre metadata and OPDS fields, following representation decisions were made:

Dates and timestamps

  • Calibre book record timestamp is represented by Atom tag <published>.
  • Calibre book record last modification timestamp is represented by Atom tag <updated>.
  • Calibre publication date is represented by Dublin Core attribute dc:issued.

Book identifiers

  • Calibre book record UUID is represented as an identifier (Dublin core attribute dc:identifier) with prefix urn:uuid:.
  • All other book identifiers are also represented by Dublin Core attribute dc:identifier.
  • Identifiers with types uri, urn, and epubbud are published as-is. Identifiers of all other types are prefixed by urn:id-type:, where id-type is the identifier type.

Authors, publishers, series, tags

  • Calibre author link is always represented in subtag <uri> of Atom tag <author>.
  • Calibre book publisher is represented by Dublin Core attribute dc:publisher.
  • Calibre book series is represented by Dublin Core attribute dc:isPartOf, referring to complete list of books in the series.
  • Calibre book series index is not represented, since Dublin Core lacks corresponding vocabulary.
  • Calibre book tag is represented by Atom tag <category> without schema or label.

Other metadata

  • Atom tag <content> is filled with Calibre book comment.
  • Calibre book annotations, ratings, last read positions and custom columns are ignored.

Other decisions

  • Feed items are usually sorted in alphabetic order by name or title. The only exception is book acquisition feed of a series, which is sorted by series index first, followed by book title.
  • All feeds are non-paginated. It is expected that a personal library saved in Nextcloud is not large enough for pagination to be necessary. However, pagination may be implemented at a later date.

Search

Search terms in OpenSearch are interpreted as a PCRE pattern.

Both patterns and the values which are searched in are normalized to Unicode form NFKC. This means that, for example, pattern fi will match ligature fi, and vice versa.

Search is case-insensitive, meaning that pattern abc will match ABC.

Search is diacritics-agnostic, meaning that pattern pate matches both pâté and patê, however pattern pâté doesn't match patê.

Matches are looked for in:

  • Book title.
  • Book description (Calibre comments).
  • Book author names.
  • Book series names.
  • Book tags.