Skip to end of metadata
Go to start of metadata

Notes from May-Jun 2012

Introduction

Source: LIDO + OAI-PMH XML Examples:

  • [^oai-tms.ycba.yale.edu-499.xml]
  • [^oai-tms.ycba.yale.edu-757.xml]

Target: CIDOC CRM RDF Examples (Pubby HTML pages):

Conventions:

  • Many of the code fragments below are Turtle, I've converted RDF->Turtle using http://any23.org
  • DO NOT use Rich Text editing, edit only the Wiki Markup. Do not fall into the fruit salad trap
  • Outstanding issues: search for #! in code, in text.
    When you fix an issue, remove these markers but leave the explanatory notes as a guidance

Object - work of art

Identifier = Object ID, Location, Title, Credit Line, Dimensions, Current Repository (building physical and legal custody keeper), Department (association?)
Documented (images, lido ID - admin data?), rights to object, rights to images of object, link to web page)

Labels

  • Why do we use double colon :: in the rdfs:label and P3_has_note? Do we need to for indexing in Lucene?
    • OWLIM Lucene indexes just the words, :: doesn't matter. But I kind of like it, it separates the parts of the "display wrap"
  • Using rdfs:label vs crm:P3_has_note vs skos:prefLabel
    • rdfs:label: primary string label of a node, eg object title, artist name, dimension "display wrap"
    • skos:prefLabel: primary string label of a SKOS thesaurus node. (This is a sub-property, so it infers rdfs:label)
    • crm:P3_has_note: any additional label/note

Dimensions

LIDO

RDF: represented in a structured way (with two dimension nodes: object/499/width and object/499/height)

  • lido:displayObjectMeasurements
    If you put this display wrap at the object level, use P3_has_note since that's not the primary label:
  • lido:extentMeasurements
    This says which object part was measured. You need to somehow group the two E54_Dimensions, then map this to a P2_has_type. Alternatives:
    • (complicated) Make an object part "Support"
    • (better) Use E16_Measurement (see this diagram measurement@crmg!).
      Note that P43 is a shortcut of the "long-cut" path P39i/P40, i.e. P43_has_dimension = P39i_was_measured_by/P40_observed_dimension, and we state both:

Inventory Number

LIDO (part of lido:repositorySet lido:type="current")

RDF

Legal Body

LIDO (part of lido:repositorySet lido:type="current")

RDF

Images

LIDO

RDF

Subject Terms (is_about)

Geographical (Getty TGN) or Concepts (Getty AAT concepts can be keywords or people).
I thought people are in ULAN

There are two types of terms we have Art and Architecture Thesauri (AAT) and Thesauri of Geographical Names (TGN). These are based on Getty Vocab and contain Getty IDs. We also have our own terms that would not fit Getty and we provide for these TMS IDs. We also identify as many textural entries / concepts as we can with an ID for example "provenance, exhibition history, etc."

TGN Places

LIDO

RDF

AAT Concepts

LIDO

RDF

Events

Creation (Production)

creator (actor)

Creator data could come from authority, this data was for YCBA purposes, however authority may not provide the complete creator info and may not facilitate linked data. We provide YCBA, ULAN or Library of Congress (LOC) identifiers where possible. Only LOC currently has linked data, we are working on mapping their URI in RDF.
You should use VIAF (http://viaf.org/) that aggregates data across ULAN, LOC and 20 national libraries. It's a most excellent resource.

LIDO

Please note that the above includes two kinds of data:

  • About the person himself
  • About the person's relation to the object (only "object related role")

You must decide whether you emit any Person information from your databases, or trust VIAF to be complete enough

RDF

death place (creator)

rather strange as not part of actor, this was added for YCBA purposes, could come from authority record

LIDO

RDF - not sure what property type to use to get at this

birth place (creator)

rather strange as not part of actor, this was added for YCBA purposes, could come from authority record

LIDO

RDF

date (event date)

LIDO

RDF

period (text time period this event occurred in)

LIDO

RDF

This is definitely not E55_Type

culture

LIDO

RDF

This is neither E55_Type nor E74_Group. It's a E4_Period@crm (see the Scope Note)

  • See BMX Issues#Theaurus Requirements for more guidelines
  • Looking at the requirements and notes between Ontotext and BM, I am confused as to what is the agreed solution.
  • Do I need anything else? I now have:
technique (support and medium)

LIDO

RDF

In this below the Medium (technique) is mapped ok, but Support should be mapped to E57_Material and you should attach it with crm:P45_consists_of and crm:P126_employed. See Material and Medium-Technique for details

* Another quick look at this to make sure I setup Support correctly: http://collection.britishart.yale.edu/id/getty/aat/14078

Provenance

Currently big block of text represented as PX3_provenance, it is just under the main object. Provenance does not currently have identifiers, it is part of an object, it may be divided into smaller components in the future ie; names, dates, and prices at which point we may need the unique identifiers.

LIDO

RDF

Exhibition History

Currently only title of exhibition, comma separated, date (YYYY format). We also have the unique exhibition ID that is part of the URI. We model conceptID terms separately under subject terms, is this correct?

LIDO

RDF

Publication

We have a text for bibliographic entry and plan to add URI to OCLC WorldCat and Google Books (at some point once these provide linked data, it will be all linked). As above term and concept ID is under subject terms.

LIDO

RDF

Acquisition

-- pending test case and LIDO

Framing History (part addition)

-- pending test case and LIDO

Conservation (modification)

-- pending test case and LIDO

Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.