Museum Linked Data Browser: The Duchamp Research Portal

View Entities:

Getting Started

Orientation for cataloguers, field specialists, and DH researchers
Orientation for developers
Common language: integration and reconciliation
Reviewing your modeled data
The model's relationship to linked.art and other linked data models

Technologies Overview

Data sources
Data layers and transforms
Actions you can take
Technology stack
Data releases
Image management
Search
Language and localization

Data Models

Basic patterns from Linked.Art
Images
Museum data
Archives data
Person, Organization and Group data
Vocabularies

Data to Curate Relationships

Direct curated relationships
Faceted relationships
Indirect relationships

The model's relationship to linked.art and other linked data models

Introduction

The data model for the Duchamp Research Portal site augments an early version of linked.art, adding predicates and data structures for modeling and integration across art, library, and archival museum systems.

Linked.Art and its early history

Linked.Art is a community-driven data model that specializes and augments the CIDOC-CRM, a linked data ontology that models knowledge as stateful entities changed by creation / destruction / modification and other events. CIDOC-CRM emphasizes the totality of modellable data in any semantic representation (RDF, JSON-LD, SPARQL access, etc). linked.art focuses on museum use cases and a human-legible JSON-LD representation that is nonetheless machine processable.

The linked.art model arose in 2017 out of the American Art Collaborative, a Mellon- and IMLS-funded project to gather the data of 14 art museums and art archives to be published as linked data.

The Design for Context model and linked.art

Although linked.art did not emit versions pre-1.0, the DfC model derives from a late 2018 commit in their model repository. We actively participate in the community, and anticipate adapting our implementations as appropriate following the release of linked.art 1.0.

We also add:

  • Archival modeling: Predicates and data structures to handle archival data in a way that is parallel to linked.art patterns. Additional archival hierarchies and cataloguing levels.
  • Library modeling: Predicates and data structures that align descriptive cataloguing (format, inscriptions, etc) and basic identity (Call numbers, Subject headings, makers, etc) from MARCXML with linked.art.
  • Additional cross-collection reconciliations: Managing vocabulary relationships between internal and external controlled vocabularies. Aligning different vocabularies across repositories within an institution. Addressing other data alignment enhancements.
  • IIIF image capabilities: The International Image Interoperability Framework – IIIF – is an additional community-driven set of specifications that we use for website delivery of images. During deployment, some metadata is transformed in ways that support the creation of IIIF image manifests.

Differences from linked.art

  • The DRP model uses the type ManMadeObject instead of the preferred and more neutral HumanMadeObject as this change was made to linked.art after the version of the model we adopted (planned to be changed sometime after linked.art 1.0 is released).

  • We do not use the type-of-types pattern.

  • We use "label" instead of "_label" - see core properties.

  • LinguisticObject and Identifier nodes use "value" as the property for the linguistic or numeric content of the node instead of "content" - see identifiers and statements about a resource.

  • Although in the JSON-LD both models use Name to describe titles, person names, and other linguistic identifiers, in this model's RDF this is the la:Name stub class rather than linked.art's synthetic crm:E33_E41_Linguistic_Appellation class - see their section on names.

  • Human-readable timespan dates are simply expressed with a "label" property on the TimeSpan.

References