Version 12 by lec.maj
on May 29, 2012 22:30.

compared with
Current by Vladimir Alexiev
on May 28, 2013 17:43.

This line was removed.
This word was removed. This word was added.
This line was added.

Changes (4)

View Page History
h2. Object - work of art ? (identifier = Object ID, Location, Title, Credit Line, Dimensions, Current Repository (building physical and legal custody keeper), Department (association?)
{excerpt}YCBA data conversion from LIDO XML to CIDOC CRM RDF{excerpt}

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


h2. 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|Material and Medium-Technique] for details
<> a crm:E12_Production ;
crm:P32_used_general_technique <> ,
<> .
<> a crm:E55_Type , skos:Concept ;
skos:inScheme aat:support ; skos:prefLabel "canvas" .
<> a crm:E55_Type , skos:Concept ;
skos:inScheme aat:medium ; skos:prefLabel "oil paint" .
{code}\*&nbsp;{color:#993300}Another quick look at this to make sure I setup Support correctly:{color}&nbsp;[|]

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

This is definitely not E55_Type

a crm:E55_Type , skos:Concept ; 
a crm:E4_Period ;
skos:inScheme ycba_aat:Period ; 
skos:prefLabel "18th century"{code}
- 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&nbsp;[Handling Time Periods in STAR|]&nbsp;to assign actual dates to such time-spans, using the label
- {color:#993300}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.&nbsp;{color}
- {color:#993300}Production&nbsp;dates:&nbsp;{color}[|]
- {color:#993300}Period&nbsp;{color}[|]
- &nbsp;

h2. Events

h4. Exhibition History


h4. Publications


h4. Provenance


h4. Acquisition

\-\-{excerpt}Some feedback on the YCBA mapping

{color:#993300}Lec updates:{color}

All my fixes have been crossed out. {color:#993300}New comments on brown color&nbsp;{color}

For testing I am only updating these two complete records:

* [|]
* [|]\\{excerpt} based on a *cursory* examination of oai_tms.ycba.yale.edu_499.rdf sent by [] on 9 May 2012.
Many of the fragments below are TTL, I've converted it to Turtle using []
- {color:#993300}Why do we use double colon :: in the rdfs:label and P3_has_note? Do we need to for indexing in Lucene?&nbsp;{color}
- should use {{crm:P3_has_note}} vs {{rdfs:label}} more consistently
-* {color:#993300}Looks like we use has_note, rdfs:label, and skos:prefLabel \-\- I tried to define when to use which, is this correct?{color}\-*\** {color:#993300}{*}rdfs:label \--&nbsp;*{color}{color:#993300}{*}primary representation ie; title, artist name{*}{color}*\-*\* {color:#993300}P3_has_note \-\- s{color}{color:#993300}econdary display{color}{color:#993300}&nbsp;ie; dimensions{color}-** {color:#993300}skos:prefLabel \-\- ??{color}
- -[]- -misspelled-
-- This causes an invalid URI {{<crm:E55_Type>}} (prefixed yet enclosed in angle brackets)
{code:xml}<rdf:Description rdf:about="">
<rdf:type rdf:resource="crm:E55_Type" />
- This causes a blank node that is not connected to anything (same for other legal bodies)[]
{code:xml}<crm:P1_is_identified_by rdf:resource="500303557" />{code}
- re []
-- -skos:inScheme ycba_tgn:local : that's not a term value, so it should not be inScheme-
--* {color:#993300}I removed all the skos:inScheme that have: local{color}
-- -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|]
--* {color:#993300}I represented this based on how Barry suggested using wgs84, awaiting some modification to RDFer for parsing lat,long into&nbsp;separate&nbsp;fields. Please take a look to see if I am missing anything:&nbsp;{color}[]
- <[]> 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)-
-* {color:#993300}I represented this the way that BM has done now, crm:E54_Dimension is gone, so this does not have the&nbsp;{color}{color:#881280}lido:displayObjectMeasurements{color} {color:#993300}and&nbsp;{color}{color:#881280}lido:extentMeasurements.&nbsp;{color}{color:#993300}Do we agree to add crm:E54_Dimension to both as I had before with the structured way for width and height?{color}
- -crm:P82a_end_of_the_end "1752" : misspelt, that's P82b.-
-- -Also, you better put a type- {code}"1752"^^xsd:gYear{code}
{color:#993300}Production Date looks a bit different for YCBA and BM, we use&nbsp;{color}[P4_has_time-span|]{color:#993300}&nbsp;BM does not. Here is my example:&nbsp;{color}[|]
- This is neither E55_Type nor E74_Group. It's a [E4_Period@crm] (see the Scope Note)
a crm:E55_Type , skos:Concept ; 
a crm:E74_Group ;
skos:inScheme aat:Culture ;  
skos:prefLabel "British"{code}
-- (!) See [BMX Issues#Theaurus Requirements] for more guidelines
-- {color:#993300}Looking at the requirements and notes between Ontotext and BM, I am confused as to what is the agreed solution.&nbsp;{color}
-- {color:#993300}Do I need anything else? I now have:{color}
-- {code}
a crm:E4_Period ;a rdfs:label "British" ;a skos:inScheme aat:Culture
- &nbsp;
- &nbsp;