Description
As we (correctly again IMO) decided in #400, each part of an entity should have its own identity and description; we should not embed blank nodes for the parts within the main entity record.
However as the relationship is from the part to the whole, when the record for the whole is being rendered, there is no reference to the parts that a client might want to retrieve and display. For example, when rendering the record for a painting, it would be useful to also render the (likely very minimal) record for the frame of the painting. So, we need a way for the client to discover the URIs of the parts of the current object.
There are several options:
1 URI pattern
Enforce a URI pattern based on the main entity's URI to an API that lists the inverse relationships.
For example, if the main entity is https://data.example.museum/object/1 then the way to get the parts would be to retrieve https://data.example.museum/object/1/part (which might then also have URIs like .../object/1/part/1 but might be /object/2 or any other URI)
The advantage is that it's easy, we can keep the response format entirely consistent with the rest of the APIs, and can be materialized into a static file. It could either be per predicate, or all of the predicates for the entity.
There could be an entry in the record pointing to the URI (or URIs) which would allow the decoupling of the main entity's URI from the API endpoint, similar to the service pattern in IIIF, which might be useful anyway for other hypermedia services.
2 Triple Pattern Fragments
Instead of the URI being constructed from the main entity, we could use the Triple Pattern Fragments specification.
This instead has a single service endpoint where the client gives the predicate and object URIs, and gets a list of the matching triples.
For example, https://query.wikidata.org/bigdata/ldf?subject=&predicate=http%3A%2F%2Fschema.org%2Fabout&object=http%3A%2F%2Fwww.wikidata.org%2Fentity%2FQ42 is a TPF for entities in wikidata that are about Q42 (Douglas Adams). The response would actually be in JSON-LD, rather than the HTML from the above URI (which you can get by adding an Accept header to the request).
The advantage is that it's an existing specification that has paging for long lists, and there are implementations of both clients and servers (though typically needing a SPARQL interface to query). There is only a single URI needed, the base endpoint, and then the current object's URI is a parameter to that service. This means that it could be hosted completely independently from the main data, even by another organization that has harvested the data and indexed it.
Discovering the base endpoint could be documentation based (as it's static for all entities) or boilerplate added into the entities' records to allow a system to follow it directly rather than needing to be configured beforehand.
My preference is the first option:
- TPF is good if the alternative is SPARQL, but it's still a bit more complex than we actually need.
- It would be very hard to implement in a static site, which is one of our core design principles, and the URI pattern is just as good
- TPF explicitly does not allow blank nodes, which we might need (e.g. reference to a Person from object's creation bnode to get from artist to their objects)
- We don't need arbitrary queries, just some class specific inverses based on the API structure
- We can make sure it fits in with all of the other design patterns and decisions more easily