search

linked-art / linked.art

Development of a specification for linked data in museums, using existing ontologies and frameworks to build usable, understandable APIs
https://linked.art/
Other
93 stars 14 forks source link

locate art object using a CMS exhibition ID and a CMS exhibition object ID #354

Open beaudet opened 4 years ago

beaudet commented 4 years ago

We would like to be able to use the Linked Art API to find an art object using only an internal exhibition ID and that exhibition object's ID which, at least in our case, is not venue-dependent.

Example: our art object has a shortcut field representing its last use as an exhibition object, for example: 2824-5 which can be parsed as meaning TMS exhibition ID 2824, exhibition object ID 5.

We would like to be able to locate art objects using only these two pieces of information and preferably without having to make a multitude of network calls.

I can imagine a REST call that looks something like: https://api.nga.gov/linked.art/exhibitions//2824///5 to represent a query that first returns a list of exhibitions having a specific property (in this case an internal TMS ID) matching 2824 and a subsequent sub-query that searches that result to look for art objects having an internal ID matching the value 5.

The alternatives seem to be either

  1. a SPARQL query, which if I am not mistaken we have been very clear should not be required to make use of linked art by all applications,
  2. a custom API implementation which would lead to lack of software interoperability and thus undermines one of the main benefits of standardizing on linked art, or
  3. using a brute force technique to make sufficient network calls to traverse the set of all exhibitions, parsing each document, and searching for the object of interest.

While option 3 might be able to be considered a level-0 implementation, I for one, do not consider that approach to be practical. Instead, I would hope that software is available to read the data provided by a level 0 implementation once (or periodically for refresh) and then in turn, makes a STANDARD search implementation available for use by application software. Whether linked art adopts an existing search implementation (Solr?) or defines a new search implementation (REST presumably?), I feel strongly that it needs to happen and support use cases like I have identified in this issue. An API like this will vastly increase developer happiness and it will also provide an on-ramp for developers who have not worked with linked data in the past.

azaroth42 commented 4 years ago

Agreed (of course :) ) though would propose that like other search API calls, we should get the basics working first of retrieving the individual entity descriptions, and then look to search. So I propose defer for this one for now?

beaudet commented 4 years ago

Deferring is fine with me and I definitely agree on the priorities so long as: 1. we eventually tackle this problem and it's part of the "Linked Art API" as opposed to stopping short of providing that type of functionality in the standard, and 2. the solution for retrieving the individual entity descriptions does not somehow preclude our ability to layer additional functionality on top to provide this functionality... and if it does, that we be open to revising the spec to accommodate both modes.

azaroth42 commented 4 years ago

Absolutely agreed!