Finds entities (people, places) in getty. Meant to be used with cwrc-public-entity-dialogs where it runs in the browser.
Although it will not work in node.js as-is, it does use the Fetch API for http requests, and so could likely therefore use a browser/node.js compatible fetch implementation like: isomorphic-fetch.
getty supports sparql, but SPARQL has limited support for full text search. The expectation with SPARQL mostly seems to be that you know exactly what you are matching on. So, a query that exactly details the label works fine:
SELECT DISTINCT ?s WHERE {
?s ?label "The Rolling Stones"@en .
?s ?p ?o
}We'd like, however, to match with full text search, so we can match on partial strings, variant spellings, etc. Just in the simple case above, for example, someone searching for The Rolling Stones would have to fully specify 'The Rolling Stones' and not just 'Rolling Stones'. If they left out 'The' then their query won't return the result.
There is a SPARQL CONTAINS operator that can be used within a FILTER, and that matches substrings, which is better, and CONTAINS seems to work with getty, e.g.
http://vocab.getty.edu/sparql.json?query=SELECT DISTINCT ?s ?label WHERE {
?s rdfs:label ?label .
FILTER (CONTAINS (?label,"Rolling Stones"))
but again, CONTAINS only matches substrings.
There is at least one alternative to CONTAINS - REGEX - but as described here: https://www.cray.com/blog/dont-use-hammer-screw-nail-alternatives-regex-sparql/ REGEX has even worse performance than CONTAINS.
A further alternative, which we've adopted, is the custom full text SPARQL search function through which Getty exposes it's underlying lucene index, as described here: http://vocab.getty.edu/doc/queries/#Full_Text_Search_Query and here: http://serials.infomotions.com/code4lib/archive/2014/201402/0596.html
The endpoint does not, however, support HTTPS. And so, we proxy our calls to the lookup through own server: https://lookup.services.cwrc.ca/getty to thereby allow the CWRC-Writer to make HTTPS calls to the lookup. We can’t make plain HTTP calls from the CWRC-Writer because the CWRC-Writer may only be loaded over HTTPS, and any page loaded with HTTPS is not allowed (by many browsers) to make HTTP calls.
We also proxy calls to retrieve the full page description of an entity, again to allow calls out from a page that was itself loaded with https. The proxy:https://getty.lookup.services.cwrc.ca which in turn calls http://vocab.getty.edu
Update v.2.3.0
GETTY supports HTTPS now, so we are no longer using the proxy server. Instead we acess https://vocab.getty.edu directly.
npm i getty-entity-lookup
import gettyLookup from 'getty-entity-lookup';
where the query argument is an object:
{
entity: 'The name of the thing the user wants to find.',
options: 'TBD'
}and all find methods return promises that resolve to an object like the following:
{
"id": "http://vocab.getty.edu/ulan/500311165",
"name": "University of Pennsylvania, Lloyd P. Jones Gallery",
"nameType": "Corporate",
"originalQueryString": "jones",
"repository": "getty",
"uri": "http://vocab.getty.edu/ulan/500311165",
"uriForDisplay": "https://getty.lookup.services.cwrc.ca/ulan/500311165"
}There are a further four methods that are mainly made available to facilitate testing (to make it easier to mock calls to the getty service):
where the query argument is the entity name to find and the methods return the getty URL that in turn returns results for the query.
CWRC-Writer-Dev-Docs describes general development practices for CWRC-Writer GitHub repositories, including this one.
We use fetch-mock to mock http calls (which we make using the Fetch API rather than XMLHttpRequest).
We use Travis.
We follow SemVer, which Semantic Release makes easy.
Semantic Release also writes our commit messages, sets the version number, publishes to NPM, and finally generates a changelog and a release (including a git tag) on GitHub.