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
  • Indexing Exhibitions
  • Suggestions
  • Decision on Exhibition indexing
  • Format
  • Filter out exhibitions
  • Front-end integration decisions
  • Out of scope but have been discussed

RFC 068: Exhibitions in Content API

PreviousRFC 067: Prismic API ID casingNextRFC 069: Catalogue Graph Ingestor

Last updated 2 days ago

Exhibitions are to be added to Events search, becoming Events & Exhibitions search. We'll therefore be working on indexing Exhibitions in a more intentional manner. That indexing and subsquent API endpoint will power the Events & Exhibitions search as well as, eventually, the existing listing pages.

Last modified: 2025-02-18T17:15:49+00:00

Indexing Exhibitions

I can think of two ways to go about indexing Exhibitions for ranking against Events to make sense and be easier to handle.

Suggestions

Exhibitions-only index

  • We create a new index (exhibitions) and index exhibition documents in there.

  • We then create a new endpoint (events-exhibitions?) that .

  • We use that endpoint in /search/events.

Meaning that the /events endpoint can then still be used for events listing pages, and a separate new one for exhibitions can be used in exhibitions listing pages.

This feels cleaner and clearer, but might end up meaning duplicate work (e.g. we want to support a new field).

Exhibitions added to Events index

  • We pull Exhibitions in the existing events index, with something marking them as Exhibitions, possibly the format field (see section below).

  • Individual listing pages (/events, /exhibitions) would be rendered using a filter to ensure only the relevant ones are displayed.

It would simplify the work when adding filters or maintaining the indices, only doing it once, but is possibly harder to maintain in the long run, should the two content types grow apart or more complicated.

Decision on Exhibition indexing

After RFC discussions, we'll aim to do a mix of the two solutions above.

  1. Create a new exhibitions index comprised of all exhibitions, coupled with a new /exhibitions endpoint. They would be formatted to work on Exhibitions listing pages and individual Exhibition fetching. This will be out of scope for the "Exhibitions search" milestone.

  2. Add exhibitions to the events index, where they would fully be considered to be Events. This will ensure that, should we want to bring the events search further, we can tweak the indexed Exhibition documents to match without having to tweak the Prismic model. For example, we can currently filter Events with "Catch-up events only"/isAvailableOnline. This is not a field in the Exhibition content type model. If we only used the exhibition index, we'd have to go add it in, even though it's not useful for exhibition listing pages. So it is a separation of concern.

Format

Meaning the value of "format" should differ in the filter and aggregrations objects versus the display object. I suggest we concatenate the Exhibition type with the string "Exhibition" in the query object format, so both are queryable.

For the sake of this document, let's determine that the "custom UUID" for the Event type "Exhibition" (which does not exist in Prismic) is abcdef-123. In this example, this document is of Exhibition type "Season":

  display: {
    format: {
      type: 'EventFormat',
      id: "Xk5QHxEAACUAe4gV",
      label?: "Season"
    };
  },
  query: {
    format: ['Exhibition', 'Season'] // This way it's queryable under both identifiers
  },
  filter: {
    format: "abcdef-123"
  }
  aggregatableValues: {
    format: """{"type":"EventFormat","id":"abcdef-123","label":"Exhibition"}"""
  }

May it be noted that having a different value for format in those objects is not the preferred way of operating; this is an exception that will be documented in the code. We considered adding a new field (label), but it seemed overkill for now, as only Exhibitions need a different value from format. Should we want to have a third Content Type that should "become an event", we might want to change the logic across.

Filter out exhibitions

We won't be creating a new endpoint, so we need the capacity to filter out Exhibitions to feed Events listing pages. I suggest we do so with a must_not match query.

"must_not": {
  "match": { 
    "filter.format": "abcdef-123"
  }
}

Front-end integration decisions

  • Search tab title to be changed from "Events" to "Events & Exhibitions".

  • Metadata copy changes to include exhibitions.

Aside from the last two, we're not referring to Exhibitions anymore. Within search, exhibitions are considered to be a type of Event. So:

  • No change to search events URL (/search/events).

  • "Event type" filter keeps its name.

  • The future date filter will also just mention events, for example "all future events".

Out of scope but have been discussed

  • Redirect events/past?availableOnline=true to /search/events?isAvailableOnline=true. The other listing pages stay as is as they serve a different purpose than the search page.

All exhibitions will fit under the Format filter "Exhibition":

but their format on the card (yellow label) will be the Exhibition Format that was selected in Prismic (e.g. Display, Installation...):

Exhibitions should use (will there be renaming to do?), with the required tweaks where displayed fields differ (e.g. "Now on" dot).

the same rendering component on the Front-end
searches through both the events and the exhibitions index
Format