
Source LIDO + OAI-PMH Example:
RDF + CRM Examples:
- http://collection.britishart.yale.edu/id/page/object/499
- http://collection.britishart.yale.edu/id/page/object/757
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
- I represented this based on how Barry suggested using wgs84, awaiting some modification to RDFer for parsing lat,long into separate fields. Please take a look to see if I am missing anything: http://collection.britishart.yale.edu/id/tgn/7002445/location
- <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?
http://collection.britishart.yale.edu/id/thesaurus/indetifier/inventory-number:misspelled- This causes an invalid URI <crm:E55_Type> (prefixed yet enclosed in angle brackets)
- This causes an invalid URI <crm:E55_Type> (prefixed yet enclosed in angle brackets)
- This causes a blank node that is not connected to anything (same for other legal bodies) http://collection.britishart.yale.edu/id/legal_body/500303557
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)
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
AAT
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 LOC identifiers where possible. Only LOC currently has linked data, we are working on mapping their URI in RDF.
LIDO
death place (creator)
rather strange as not part of actor, this was added for YCBA purposes, could come from authority record
LIDO
RDF
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
- I think this is better mapped to E52_Time-Span since it's not a cultural period and has only a time aspect
- Consider using the excellent work on Handling Time Periods in STAR to assign actual dates to such time-spans, using the label
- I already have time span defined with actual dates, the period is to provide label, if there is something else I need to do please let me know. I removed E55_Type.
- Production dates: http://collection.britishart.yale.edu/id/page/object/499/production/date
- Period http://collection.britishart.yale.edu/id/page/getty/aat/300111159
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
- crm:P82a_end_of_the_end "1752" : misspelt, that's P82b.
Also, you better put a type
Production Date looks a bit different for YCBA and BM, we use P4_has_time-span BM does not. Here is my example: http://collection.britishart.yale.edu/id/object/499/production
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