Skip to end of metadata
Go to start of metadata
You are viewing an old version of this page. View the current version. Compare with Current  |   View Page History

Source LIDO + OAI-PMH Example:

RDF + CRM Examples:

General

based on a cursory examination of oai_tms.ycba.yale.edu_499.rdf sent by [~lec.maj@yale.edu] on 9 May 2012.
Many of the fragments below are TTL, I've converted it to Turtle using http://any23.org

  • Why do we use double colon :: in the rdfs:label and P3_has_note? Do we need to for indexing in Lucene? 
  • should use crm:P3_has_note vs rdfs:label more consistently
    • Looks like we use has_note, rdfs:label, and skos:prefLabel -- I tried to define when to use which, is this correct?-* rdfs:label -- primary representation ie; title, artist name-P3_has_note -- secondary display ie; dimensions-** skos:prefLabel -- ??
  •  

Object - work of art ? (identifier = Object ID, Location, Title, Credit Line, Dimensions, Current Repository (building physical and legal custody keeper), Department (association?)

  • re http://collection.britishart.yale.edu/id/tgn/7008591/coordinates
    • skos:inScheme ycba_tgn:local : that's not a term value, so it should not be inScheme
      • I removed all the skos:inScheme that have: local
    • a crm:E47_Spacial_Coordinates : misspelt
    • crm:P90_has_value "54.0000, -4.5000" : better express this in a structured way.
    • You may want to consider the paper Integration of Coordinate Information in CIDOC CRM
  • <http://collection.britishart.yale.edu/id/object/499/dimension> a crm:E54_Dimension
    I can see the DisplayWrap crm:P3_has_note "78 1/4 x 48 1/8 inches (198.8 x 122.2 cm)"
    but should also be represented in a structured way (with two dimension nodes: object/499/width and object/499/height)
  • I represented this the way that BM has done now, crm:E54_Dimension is gone, so this does not have the lido:displayObjectMeasurements and lido:extentMeasurements. Do we agree to add crm:E54_Dimension to both as I had before with the structured way for width and height?

documented (images, lido ID - admin data?), rights to object, rights to images of object, link to web page, )

--

Subject Terms (is_about) - geographical (tgn) or concepts (aat concepts can be keywords or people)

This is definitely not E55_Type

  • 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:
  •  

Events

Creation (Production)

-- creator

-- medium 

-- support

-- technique

-- date of creation

-- culture

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/page/getty/aat/14078

Provenance

Currently big block of text represented as PX3_provenance

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

--

Acquisition - [TBD]

--

Framing History (part addition) - [TBD]

--

Conservation (modification) - [TBD]

--


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