Request For Comments (RFCs)
  • Request for comments (RFC)
  • RFC 001: Matcher architecture
  • RFC 002: Archival Storage Service
  • RFC 003: Asset Access
  • RFC 004: METS Adapter
  • RFC 005: Reporting Pipeline
  • RFC 006: Reindexer architecture
  • RFC 007: Goobi Upload
  • RFC 008: API Filtering
  • RFC 009: AWS account setup
  • RFC 010: Data model
  • RFC 011: Network Architecture
  • RFC 012: API Architecture
  • RFC 013: Release & Deployment tracking
    • Deployment example
    • Version 1
  • RFC 014: Born digital workflow
  • RFC 015: How we work
    • Code Reviews
    • Shared Libraries
  • RFC 016: Holdings service
  • RFC 017: URL Design
  • RFC 018: Pipeline Tracing
  • RFC 019: Platform Reliability
    • CI/CD
    • Observability
    • Reliability
  • RFC 020: Locations and requesting
  • RFC 021: Data science in the pipeline
  • RFC 022: Logging
    • Logging example
  • RFC 023: Images endpoint
  • RFC 024: Library management
  • RFC 025: Tagging our Terraform resources
  • RFC 026: Relevance reporting service
  • RFC 026: Relation Embedder
  • RFC 027: Pipeline Intermediate Storage
  • RFC 029: Work state modelling
  • RFC 030: Pipeline merging
  • RFC 031: Relation Batcher
  • RFC 032: Calm deletion watcher
  • RFC 033: Api internal model versioning
  • RFC 034: Modelling Locations in the Catalogue API
  • RFC 035: Modelling MARC 856 "web linking entry"
  • RFC 036: Modelling holdings records
  • RFC 037: API faceting principles & expectations
  • RFC 038: Matcher versioning
  • RFC 039: Requesting API design
  • RFC 040: TEI Adapter
  • RFC 041: Tracking changes to the Miro data
  • RFC 042: Requesting model
  • RFC 043: Removing deleted records from (re)indexes
  • RFC 044: Tracking Patron Deletions
  • RFC 045: Work relationships in Sierra, part 2
    • Work relationships in Sierra
  • RFC 046: Born Digital in IIIF
  • RFC 047: Changing the structure of the Catalogue API index
  • RFC 048: Concepts work plan
  • RFC 049: Changing how aggregations are retrieved by the Catalogue API
  • RFC 050: Design considerations for the concepts API
  • 051-concepts-adapters
  • RFC 052: The Concepts Pipeline - phase one
  • RFC 053: Logging in Lambdas
  • RFC 054: Authoritative ids with multiple Canonical ids.
  • RFC 055: Genres as Concepts
  • RFC 056: Prismic to Elasticsearch ETL pipeline
  • RFC 058: Relevance testing
    • Examples of rank CLI usage
  • RFC 059: Splitting the catalogue pipeline Terraform
  • RFC 060: Service health-check principles
  • RFC 061: Content API next steps
  • RFC 062: Content API: All search and indexing of addressable content types
  • RFC 062: Wellcome Collection Graph overview and next steps
  • RFC 063: Catalogue Pipeline services from ECS to Lambda
  • RFC 064: Graph data model
  • RFC 065: Library Data Link Explorer
  • RFC 066: Catalogue Graph pipeline
  • RFC 067: Prismic API ID casing
  • RFC 068: Exhibitions in Content API
  • RFC 069: Catalogue Graph Ingestor
  • RFC 070: Concepts API changes
  • RFC 071: Python Building and Deployment
    • The current state
  • RFC 072: Transitive Sierra hierarchies
  • RFC 073: Content API
    • Content API: articles endpoint
    • Content API: Events endpoint
    • Content API: exhibitions endpoint
    • The future of this endpoint
  • RFC 074: Offsite requesting
    • Sierra locations in the Catalogue API
Powered by GitBook
On this page
  • Events filters and aggregations
  • Filter
  • Sort
  • Aggregations
  • Exhibitions filters and aggregations
  • Filters
  • Sort options
  • Aggregations
  1. RFC 073: Content API

The future of this endpoint

This document is used to keep track of things we've considered and decided should only be considered in future versions.

  • Add a link to digital guides for Exhibitions

  • /books endpoint

  • Add partOf as a filter in Stories search. (List of series (e.g. serials - which is a scheduled list of articles, or webcomic series))

  • Functional content (/pages ?)

  • Building upon /events and /exhibitions, allowing us to have specific Search pages for them.

  • is it possible to reuse the availability model we have in the catalogue API for avaialbleOnline data in events / exhibitions?

Events filters and aggregations

Filter

  • instantiations.start.from YYYY-MM-DD

  • instantiations.start.to YYYY-MM-DD

  • instantiations.end.from YYYY-MM-DD

  • instantiations.end.to YYYY-MM-DD

  • interpretation Interpretations are useful accessibility tools for event searching. They are, for example: Captioned, BSL, Wheelchair friendly

  • place.label List of physical locations, would also include "Online".

  • format IDs corresponding to [Session, Game, Installation, Discussion, Performance, Workshop, Chill out, Shopping, Festival, Screening, SEND workshop, Late, Symposium, Gallery tour, Seminar, Study day, Walking tour]

  • partOf Part of a series or season of events

  • audience The public this is geared towards, e.g. Schools

  • contributors.contributor e.g. Facilitator, Host

  • availableOnline Was recorded and the video is made available for a rewatch online.

Sort

  • instantiations.start

  • instantiations.end

  • relevance

Default sort should be by relevance, with a fallback to id if no query is provided or where documents have the same score.

Aggregations

  • place

  • contributor

  • format

  • audience

Exhibitions filters and aggregations

Filters

  • instantiations.start.from YYYY-MM-DD

  • instantiations.start.to YYYY-MM-DD

  • instantiations.end.from YYYY-MM-DD

  • instantiations.end.to YYYY-MM-DD

  • place.label List of physical locations, would also include "Online".

  • contributors.contributor e.g. Filmmaker, Curator

  • format IDs corresponding to [Permanent Exhibition, Season, Installation]

Sort options

  • instantiations.start

  • instantiations.end

  • relevance

Default sort should be by relevance, with a fallback to id if no query is provided or where documents have the same score.

Aggregations

  • place

  • contributor

PreviousContent API: exhibitions endpointNextRFC 074: Offsite requesting

Last updated 11 months ago