AIC Linked Open Data panel Museums and the Web 2015

•Download as PPT, PDF•

1 like•348 views

Stefano Cossu

Data & Analytics

Status Quo: A Centralized Architecture

One large application (CITI) to perform all collection
management tasks

Hard to address growing, diverse needs

Departmental databases disconnected from data flow

One-way data exchange via file exports and SOAP API

Toward An Ecosystem
Mid Term

Clearly separate areas of operation

Keep existing CMS as a front-end

Ensure data preservation
Long Term

Gradually phase out isolated databases

Standardize data exchange format and protocol

Web Ontology Language (OWL)

A “machine-readable philosophical system”

Defines a Knowledge Organization System across
and beyond the Institution

Vocabularies already exist for cataloging works of art

We are looking for a more flexible model

Discovering Chained Relationships
SPARQL endpoint example:
http://collection.britishart.yale.edu/sparql/
(check out Example Queries)

Sharing Knowledge
Do we need access to large catalogs of place and person names?
Yes.
Do we want to maintain records and metadata for all the places
and people in the World?
No.
Do we want to use our own cataloging schema, create our specific
names or add metadata to the existing ones?
Yes.

Sharing Knowledge
"Corvus corax ca" by Andreas Trepte - own picture, Canada Stewart Crossing, Yukon.
Licensed under CC BY-SA 2.5 via Wikimedia Commons -
http://commons.wikimedia.org/wiki/File:Corvus_corax_ca.jpg#/media/File:Corvus_corax_ca.jpg

Thank You
scossu@artic.edu
@industrievisive
"Corvus corax (NPS)" by National Park Service - http://www.nps.gov/brca/images/raven300.jpg. Licensed under
Public Domain via Wikimedia Commons -
http://commons.wikimedia.org/wiki/File:Corvus_corax_(NPS).jpg#/media/File:Corvus_corax_(NPS).jpg

- Focus of presentation is how LD influenced our straegic decisions to implement a DAMS - Just finished research and planning, moving ahead with implementation - First phase of this project is planned to go live within the end of this year
- Our current information architecture relies on one custom-built system (CITI) that stores and manages all the collection data. - Some basic DAM features (mostly images) - Very solid and popular application (~300 AIC users, ~100 average logged in) allows us to address institution-specific feature requests quickly - However, some macro-features such as DAM clearly belong to a separate, possibly not custom-built, system - Many FMP databases that departments use to store data that should actually be shared - duplicated work and inconsistent data - Other limitation is that CITI is self-contained - it can only export data
- With DAMS project we want to create smaller, specialized systems and define clearly what each component does - CITI will remain the only management tool for collection records - CITI becomes a front-end to the DAMS for a smooth user experience for staff - Fedora repo will do one simple thing: storing and preserving data. We are in line with Fedora’s mission on this point - Ancillary tools integrate seamlessly with Fedora to provide additional functionality - Eventually one central repository should store all the data and make it available by all kinds of clients - To do that, a unified format and protocol has to be established to exchange these data
Simplified map of DAMS architecture - Storage & preservation: LAKE (Fedora) repository - Middleware (Hydra): only system that connects directly to repo - Content management: client applications (can be any REST client) - Publishing: public-facing Fedora repo (no security) - contents are filtered and exported on update - Consumers: user-facing applications
- We can’t think about collections as simply lists of objects related to other lists anymore - Relationships are becoming more complex, metadata harder to fit in a table-like schema - A graph-like structure may be more appropriate than relational database - This is one of the main reasons why we chose Fedora, which speaks RDF natively, to manage and publish our assets and their relationships with collection items
- Our first DAMS implementation step is to build an ontology that will define how our data are stored and related - An ontology (“the science of being”) defines what things mean to us, and how they are related within our area of interest - Ontologies exist for traditional artwork cataloging (CIDOC-CRM, EDM etc.) - We are still in the process of formulating an ontology that satisfies the complex needs of an encyclopedic museum - PCDM - generic concept scheme, optional but recommended as a base for more complex data model
For example, we want to represent a multi-channel video work made up of several A/V streams, as well as equipment and ancillary documentation that make up its manifestation; These parts can be used in different ways and the artwork can be arranged in multiple configurations.
But we also want to have a simple workflow for “traditional”, monolithic works which make up the vast majority of our collections. I think this is something that other museums are trying to resolve or maybe have already resolved. I am very interested to hear other use cases and possibly start a conversation about a formal ontology for cataloging these artworks.
In a graph-based data model, entities can be discovered by their relationships.
Many RDF stores support what is called “inference” or reasoning. Given some fixed rules (e.g. Artist is a subclass, or specialization, of SP), then if we define an individual as Artist, he will automatically be found under the SP category as well.
- One great advantage of LOD is sharing information: (points ^^) - There are abundant ontologies and controlled vocabularies for the cultural heritage (Getty TGN for places, ULAN for artist names, etc.) - We don’t need to create vocabularies from scratch, and we can still keep our unique identifier systems while mapping our entities to imported vocabularies
I firmly believe that at some point we will be able to talk to birds. Assuming that, If we give this crow on the right our identifier for Picasso, he won’t understand. But if the crow knows ULAN, the Getty’s vocabulary for artist names, and we have our UID mapped to the ULAN UID, he will know what we are talking about.
- Visualizing Linked Data is another challenge - Often networks of information are so dense that they look as beautiful as they are unusable - But when harnessed, these tools can become extremely useful and informative - Linked Visions project about Whistler and Roussel: LinkedJazz, tech tour, exhibition June 2015

AIC Linked Open Data panel Museums and the Web 2015

Recommended

Recommended

More Related Content

Similar to AIC Linked Open Data panel Museums and the Web 2015

Similar to AIC Linked Open Data panel Museums and the Web 2015 (20)

More from Stefano Cossu

More from Stefano Cossu (12)

Recently uploaded

Recently uploaded (20)

AIC Linked Open Data panel Museums and the Web 2015

Editor's Notes