
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, )
--
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
Subject Terms (is_about) - geographical (tgn) or concepts (aat concepts can be keywords or people)
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
Events
Exhibition History
--
Publications
--
Provenance
--
Acquisition
--Some feedback on the YCBA mapping
Lec updates:
All my fixes have been crossed out. New comments on brown color
For testing I am only updating these two complete records:
- http://collection.britishart.yale.edu/id/page/object/499
- http://collection.britishart.yale.edu/id/page/object/757
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 -- ??
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
- 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?
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
- 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:
Labels:
None