Getty Call Paths

Every outbound request the Getty Tag check makes, which host serves it, and what happens when a firewall blocks it. Written for whoever approves the exception.

One host, one port, TLS only. The application makes no unencrypted connections, and the rule is enforced in the HTTP transport rather than at each call site, so a redirect cannot downgrade one either.

What to allow

One host. Verifying terms live needs it; everything else the Getty Tag check does — cleaning, structural checks, and the bundled offline term list — runs with no network at all.

Host	Port	Purpose	Needed for
vocab.getty.edu	443 · TLS	SPARQL queries against the Art & Architecture Thesaurus	Live check
aatdownloads.getty.edu	—	No longer contacted. Earlier versions downloaded the bulk archive from here over plaintext HTTP; that call was removed because the host serves no TLS. Any existing allow rule for it can be withdrawn.	Not required
fonts.googleapis.com	—	Not used. The application ships its own fonts.	Not required

The call paths

Only the solid lines cross the network, and both end at the same host on 443. The dashed leg is a file the user already has: building a term list from a Getty archive opens it locally and sends nothing. Term lookups pass through an in-memory cache first, so a sheet of ten thousand rows built from thirty distinct tags produces roughly thirty requests, not ten thousand.

Request by request

Reachability probe

vocab.getty.edu

Fetches one fixed, well-known concept to decide whether the service is usable from this machine, so the answer is shown before a check runs rather than discovered afterwards. Deliberately not a search — a probe should not depend on query syntax staying still.

It runs once a session, the first time the live source is selected, and the answer is kept. Revisiting the screen or switching the source costs nothing further; a further probe happens only when somebody presses Check again. An unreachable host therefore produces one failed request, not a stream of them.

GET https://vocab.getty.edu/aat/300046300.json

FrequencyOnce per session · manual recheck

Timeout6 seconds

Response~2 KB JSON

Term lookup

vocab.getty.edu

Asks whether one tag exists in the thesaurus. The tag text travels in the query string; nothing else from the spreadsheet is sent. Answered from the cache when the same tag has already been asked about during the run.

GET https://vocab.getty.edu/sparql.json?query=<SPARQL>

FrequencyOnce per distinct tag

Timeout15 seconds

ResponseUnder 1 MB, capped

Archive import

No network

Runs only when somebody presses Build list from a Getty archive. Opens a Getty relational archive already on the machine, extracts the English terms, and writes a term list beside it. No socket is opened and nothing leaves the workstation.

Earlier versions fetched that archive from aatdownloads.getty.edu over plaintext HTTP. The host serves no TLS, so the call was removed rather than left unprotected; whoever wants a fresher list obtains the archive separately and points the application at it.

open <chosen path>/aat_rel_<mmyy>.zip

FrequencyManual only

RequestsNone

Reads~73 MB from disk

What leaves the machine

Only the tag text itself — controlled-vocabulary terms such as aerial photographs — and only when the live check is selected. The requests carry no collection metadata, no titles, no file names, no identifiers, and no credentials. Getty requires no account and the application holds none.

Not sent: the spreadsheet, any column other than Tags, file paths, machine or user names.

Not stored by us: responses live in memory for the duration of one check and are discarded when it ends.

Written to disk only on request: the term list built from an archive, beside the archive it was built from.

If it is blocked

Blocking is handled as a known state, not an error. A failed lookup is recorded as “could not be checked” and never as “this term is wrong” — a false accusation would send a cataloguer to re-verify metadata that was already correct.

Live check blocked: the indicator turns red before the run and names the cause — blocked host, DNS failure, or TLS interception. Cleaning, structural checks, and the offline list all continue to work.

Everything blocked: the bundled term list still answers. It ships inside the application — the English AAT terms from the Getty archive that build was made with — so term checking degrades to a dated source rather than stopping.

Both blocked: everything except term verification still runs, which is the half that catches the characters that break a CONTENTdm upload.

Two things worth raising in review

http:// appears inside the request body, and is not a connection. Inspecting one of these queries — at a proxy, in a TLS-terminating gateway, or in any egress log that records query strings — shows the string http://vocab.getty.edu/aat/ inside the SPARQL text. It is not an address and nothing dials it. In RDF a URI is an identifier compared by exact string equality, and Getty minted the AAT identifiers with the http scheme, so the thesaurus literally holds <http://vocab.getty.edu/aat/300128222> as that concept's name. Rewriting it to https would change the name, match nothing, and make every tag report as absent from the vocabulary — a silent, total false negative with no error raised. The same identifiers come back in the responses for the same reason. The connection carrying all of it is HTTPS on 443.

Any list built from an archive is a snapshot. It answers for the day that archive was published and grows staler from there, which is why the publication date is written into the filename. Getty said it stopped refreshing these datasets after January 2026; should it publish again, a rebuilt list follows the newer archive and the date moves with it. The live endpoint is the only current source either way.

For a rule that inspects rather than allows

Expect: TLS to vocab.getty.edu on 443 only. One probe per session, then a short burst of small GETs during a check — one per distinct tag, roughly thirty for a typical sheet — then nothing. No polling, and no retry loop against a host that is refusing.
Do not expect: any connection on port 80, to any host, ever. The transport refuses a non-HTTPS request before the socket opens, redirects included, and reports it as refusing an unencrypted connection.
Ignore: http:// strings inside those query bodies and responses. See above — they are vocabulary identifiers, not egress.
TLS interception: works, but the probe names it as the cause when a certificate is rejected, so a red indicator on this screen is a useful first place to look.