The National Gallery of Art open data is a daily CSV export of 130,000 artworks

A collection released into the public domain

The National Gallery of Art serves the United States by welcoming all people to explore and experience art, creativity and shared humanity, and the open data program is the institutional expression of that. The README describes making certain data about the collection available to scholars, educators and the general public in CSV format, to support research, teaching and personal enrichment, to promote interdisciplinary research, to encourage fun and creativity, and to help people understand the inspiration behind great works of art.

The legal position is unusually clean. To the extent permitted by law, the Gallery waives any copyright or related rights it might have in the dataset and releases it under the Creative Commons Zero designation. In practice that means the data can be downloaded free of charge without seeking authorization, and the repository's licence is CC0-1.0.

That is a different proposition from the gallery's images, which are handled by a separate open access program, and it is a different proposition again from a museum that publishes a dataset with terms attached. Here the terms are mostly about conduct: please consider providing attribution to or citing the National Gallery of Art's Collection Dataset when using the data for research purposes, and please do not use the Gallery's logo or make any representation, express or implied, that the Gallery endorses your work without first acquiring prior written permission.

The policy statement was last updated in April 2021, and the README credits the museum community for inspiration, specifically the Metropolitan Museum of Art and its open access policy. For a dataset that people will copy into courses and tools, that request for attribution, and the request not to imply endorsement, are the two things to get right.

What the records actually cover

The dataset provides data records relating to the 130,000+ artworks in the collection and the artists who created them. That is the whole scope, and it is worth being precise about it, because a collection record is a description rather than an object.

A record describes an artwork: who made it, when, in what medium, with which dimensions, in which department, and with links and references to the images. The artists are first class too, with their own records, which is what makes the dataset usable for questions that cross the object, such as which artists are represented in multiple departments.

The format is CSV with UTF-8 encoding, and the README points at a data dictionary that fully describes the dataset. The dictionary lives in the documentation directory of the repository, which is the file to read before you write a single query, because the field names and their null conventions are the part of a published dataset that most often breaks analysis code.

The repository layout supports that reading-first approach. There is a data directory holding the published files, the documentation directory with the dictionary, a scripts directory, a sql_tables directory, an ARCHITECTURE.md file at the top level, and a tests directory. The sql_tables directory in particular suggests the data is also made available in a form that can be loaded into a database, which is the practical way to work with a collection of this size.

The primary language of the repository is Python, which fits a scripts and tooling directory rather than a library.

The images are not in the dataset, and that is the first limitation

The first of the additional usage guidelines is the one that decides whether the dataset suits your project: images and media files are not included in the dataset.

The wording is precise. Links and references to images are contained in the dataset, but the image files themselves are not included in the dataset or in the open data program described above. The open access images live in a separate program, with its own pages on the museum's site, and this repository is about the descriptive records.

For a researcher building a catalogue, a teaching tool that lists and filters works, or a dataset for text analysis over titles, artists and provenance, that is exactly what you want, and the reference links make it possible to resolve a record to its image elsewhere. For a project that needs to display the pictures, this repository is the wrong starting point, and pairing it with the open access images is a deliberate second step rather than an accident.

The second limitation is temporal. The collection data is in constant flux because the collection management process is a process in continuous motion, and the dataset may not be entirely complete, correct, or up to date. It is provided as is, is updated frequently, usually once a day, and should be used at your own risk, with no representations or warranties of any kind. If you notice erroneous data, the README asks you to tell the Gallery.

Both of those are stated plainly, which is a courtesy to the people who will build on it. The practical consequences are that a record you depend on may be absent, and that a value you depend on may have changed since your last pull.

Wikidata identifiers as the join key you will want

The third guideline explains the one feature of the schema that will matter most if you link this data to anything else, and the history behind it.

In 2018 the Gallery began a program with the Wikimedia Foundation to donate open-access images and data to Wikimedia platforms. In 2022, known Wikidata identifiers were reconciled with the National Gallery's collections management system, and the dataset now includes Q-item values for the associated Wikidata records.

The identifier is the point. A name in a collection record is a string, and strings are ambiguous across institutions, with variant spellings, transliterations and name changes. A Q-item is a stable key that resolves to a record in a database that other datasets also reference, so joining the Gallery's data to Wikimedia Commons, to a Wikipedia article, or to a graph of exhibitions and movements becomes a join rather than a fuzzy match. The README gives an example, Q230673 for Dorothea Lange, a photographer, and the National Gallery encourages everyone to explore, enjoy, share, use, re-use and build with its collection on Wikimedia Commons and Wikidata.

The caveat is stated as well. The associated values should not be considered exhaustive, and new identifiers will be added over time as the data is refreshed. So the Q-item field is a best-effort bridge that improves over time, which means a pipeline built on it should tolerate a null in the field and should not assume a stable set of matched records between two successive downloads.

Working with a snapshot instead of a live API

There is an alternative way to get information about the National Gallery's collection, and it is worth contrasting the two approaches before you commit.

One route is the museum's own website and any per-object endpoint behind it. That gives you the freshest possible view of a single record, with the site's own presentation. What it does not give you is the whole collection at once, in a shape designed to be loaded, and it gives you no contract about the fields you are reading. A scraper also puts your project at the mercy of a page redesign, and it asks you to be careful about how you treat a site that is serving the public rather than publishing a dataset.

The other route is this repository, and the difference in approach is that it is a designed export rather than a capture. The fields are described in a data dictionary, the encoding is fixed as UTF-8, the format is CSV, and the refresh is stated as roughly daily. The cost is that you are working with a snapshot: if the collection changed this morning, your copy does not know yet, and the guidelines tell you plainly that records may be incomplete, incorrect or out of date.

There is also a third path for the images specifically, since the Gallery donates them to Wikimedia Commons. Commons is a file repository with its own structure and its own licensing per file, which is a different kind of dataset from a museum's own collection export, and matching records across the two is exactly what the Q-item identifiers are there to help with.

Licence, updates and what a careful user should do

The licence makes the reuse question simple. The data is released under Creative Commons Zero, the repository's licence is CC0-1.0, and the download needs no authorization. What remains are requests rather than restrictions: consider attributing or citing the Collection Dataset in research use, and do not use the logo or imply endorsement without prior written permission.

The update cycle is the operational fact to design around. The dataset is updated frequently, usually once a day, and the repository has no tagged releases at all, so there is no version number to pin. A pipeline that pulls the files on a schedule and appends what changed is the shape that fits, and one that re-reads everything each time is the shape that simply works at the cost of bandwidth.

The last push to the default branch was on 2026-10-19, and the repository is not archived, so the publication is live rather than historical.

Two habits will keep a project out of trouble. The first is to treat the export as a starting point rather than an authority, and to verify a record against the museum's own pages when it matters, which the invitation to report erroneous data implies is a normal part of the relationship. The second is to record when you pulled the data, since a daily refresh means two queries a week apart are not comparable without that timestamp. The Gallery asks for a citation anyway, and the pull date belongs in the same footnote.

Editorial conclusion

Adopt the National Gallery of Art open data when you need a research grade bulk export of collection and artist records, you can work from a daily snapshot, and you are building something where the images come from elsewhere. Do not adopt it expecting image files, per object freshness or a stable API contract, because the images are excluded and the records are explicitly provided as is and updated about once a day. Before you build on it, read the data dictionary in the documentation directory, treat any record you rely on as needing verification against the museum's own site, and plan for the case where an artwork is absent or changed between refreshes rather than treating the export as the source of truth.

Frequently asked questions

Official sources

1. Issues
2. License: CC0-1.0
3. NationalGalleryOfArt/opendata on GitHub
4. Project website
5. README