compared with
Current by Vladimir Alexiev
on Jul 16, 2014 10:32.

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

Changes (62)

View Page History

You must comply with [BMX Issues#Thesaurus requirements]
Each term should be both a CRM entity of appropriate type, and skos:Concept.
Each term should be both a CRM entity of appropriate type (see [#CRM Types of Thesauri]) and a skos:Concept; and should have skos:inScheme.
- (-) You have this for some (eg Agents) but not others (eg Title Type).

h3. Meta-Thesaurus

(-) Each thesaurus (ConceptScheme) used by Yale should be described in [Meta-Thesaurus and FR Names#YCBA Thesauri|Meta-Thesaurus and FR Names#YCBA Thesauri] (this section will be merged to the rest of the table)
(+)  Each thesaurus (ConceptScheme) used by Yale must be described in [Meta-Thesaurus and FR Names#YCBA Thesauri|Meta-Thesaurus and FR Names#YCBA Thesauri] (this section will be merged to the rest of the table). This applies to both Getty and YCBA-local thesauri.
There's a long list of bugs (currently in email), some are added below.
- Your thesaurus URIs must match those used in instance data, else things won’t mesh. E.g. in meta you’ve used thesauri/aspect. But the Turtle examples in my page, and Daniel’s RDF files about images, use thesauri/image/flag. If you prefer, call it thesauri/image/aspect, but then edit my examples and Daniel’s conversion to use that same ConceptScheme.

| *Meta ConceptScheme* | *comment* |
| [|]\\ | |
| [|]\\ | |
| [] | |
| []\\ | |
| [] | What's its relation to /production |
| [] | |
| [] | |
| [] | |
| [] | |
| [] | |
| [] | |
| [] | |
| [] | |
| [] | YCBA is already listed in ULAN, and you have person-institution. So do you really need this? EDG: we need this until ULAN IDs are in TMS/LIDO |
| [] | Called above /likelihood - removed, done - EDG: for commenced by, completed by, finished by |
| [] | |
| [] | |
| [] | |
| [|]\\ | |
| [|]\\ | |
| [|]\\ | |
| [] | |
| [] | |

h3. Validate Instance Schemes

This command extracts skos:inScheme statements from instance data (all Ttl files). Run it in the data/ directory:
{code:bash} grep -h inScheme ttl/* cds_ttl/* ycba2cds/* | perl -pe "s{.*inScheme }{}; s{ [;.]$}{}" | sort | uniq {code}
If you're on linux you got these tools. If you're on Windows, install [].

(+)  The current list of Concept Schemes in instances is below. Resolve it against meta:
- Schemes in instances but not in meta: are undefined
- Schemes in meta but not in instances: are either useless, or indicate a defect in instance mapping (scheme is not specified).
In particular I'm worried that the instance list is quite shorter than the meta list.
- (!) It DOES matter whether there is a trailing slash or not. My preference is to consistently use a trailing slash (so the scheme is a full prefix of the term), but that's up to you. Whatever you choose, you must be consistent

| *Instance ConceptScheme* | *comment* |
| [] | ok |
| [] | ok: but wrong in meta - done |
| [] | ok: but wrong in meta - done |
| [] | ok |
| [] | ok: But note that "16th century" is NOT a [#Period/Culture] |
| [] | ok |
| [] | ok |
| [] | ok |
| [] | ok |
| [] | ok |
| [] | For '16th century', ... |
| [|] | |
| [|]\\ | commissioned by: CO |
| []\\ | used to be thesauri/department/ |
| [|]\\ | |
| [|]\\ | |
| [|]\\ | |
| [|] | |
| [|]\\ | |
| [|]\\ | |
| [|]\\ | |
| [|]\\ | |
| []\\ | AAT Styles and Periods Facet: British, American, etc |
| []\\ | |
| []\\ | |
| []\\ | |
| [|]\\ | |
| [|]\\ | |
| [|]\\ | |
| [|]\\ | |
| [|]\\ | |
| [|]\\ | |
| [|]\\ | |
| [|]\\ | |
| []\\ | |
| []\\ | |
| [] | |
| []\\ | |

h3. CRM Types of Thesauri

Each ConceptScheme determines a CRM type (rso:hasRange), which in term determines which FRs (searches) are applicable to it. The mechanism is described in [Meta-Thesaurus and FR Names#Thesaurus to FR Compatibility|Meta-Thesaurus and FR Names#Thesaurus to FR Compatibility]. Consequently RS needs each term to be attached to a single ConceptScheme.

The CRM types are shown on the diagram at the end of that page, and listed below. For each CRM type we give the relevant ConceptSchemes. While ULAN and TGN map to one type each, AAT comprises several [Facets|] (top-level URLs) that map to different types:
- crm:E39_Actor: ULAN, YCBA People
- crm:E53_Place: TGN, YCBA Places
- crm:E31_Document (not searchable): YCBA Bibliography

h3. AAT Concept Schemes
- (-) Export AAT terms to different concept schemes. Use the actual AAT Facet as concept scheme (I may be recommending something similar to Getty as well), but isolate in a prefix definition. Eg:
(-) Declare different AAT concept schemes in the Meta Thesaurus, as per the type breakdown above. Use the actual [AAT Facet|]:
<> a skos:ConceptScheme; rdfs:label "AAT Materials".
<> a skos:ConceptScheme; rdfs:label "AAT Activities/Processes/Techniques".
<> a skos:ConceptScheme; rdfs:label "AAT Styles/Periods".
<> a skos:ConceptScheme; rdfs:label "AAT". # all the rest of AAT

(-) Export AAT terms to these different schemes, but isolate in a prefix definition:
@prefix aat_materials: <> . # Materials Facet
@prefix aat_activities: <> . # Activities Facet, includes Processes and Techniques
<> skos:inScheme aat: . # horses (animals) [prefLabel=Equus caballus (species)]: Agents facet
-- (-) You already do this for Technique but use a Yale URL for the scheme (may be ok for now, but need to change in the future)

You already do this for Technique but use a Yale scheme
aat:230058 a skos:Concept; skos:prefLabel "oil gilding";

- If a painting has a *Subject* selected from Materials, Activities or Styles then currently it cannot be found (since a term from these facets does not invoke the is/has/about FR). But such Subject is not very likely
- RS currently needs each term to be assigned to a single concept scheme.
- Each term invokes one set of FRs, as per [Meta-Thesaurus and FR Names#FR Names Table|Meta-Thesaurus and FR Names#FR Names Table].
- The "split facets" Materials; Activities; Styles invoke these corresponding FRs: made of; used technique; was present at, about period.
- Object Type, Shape, About subject (where the subject is a type or Iconclass, not Period/Agent/Place) are mapped to E55_Type and thus to FR "is/has/about"
- So if a painting has a *Subject* selected from the "split facets", currently it cannot be found through this term. But such Subject is not very likely
- {status:title=future|color=blue} eExtend RS to handle AAT as one ConceptScheme that includes a number of facets (hierarchies) for object type, material, technique, etc

h3. Brand Names

Emmanuelle: yes a fair number of our subjectActor have alternate names in addition to their preferred names.

h3. Nationality

Nationality and Profession are modeled as Groups (Gender is merely a Type), eg:
a crm:E21_Person, skos:Concept;
skos:inScheme id:person-institution;
skos:prefLabel "Alfonso Ruspagiari";
bmo:PX_gender <>;
bmo:PX_nationality <>;
bmo:PX_profession <>.

bmo:PX_gender rdfs:subPropertyOf crm:P2_has_type .
bmo:PX_nationality rdfs:subPropertyOf crm:P107i_is_current_or_former_member_of .
bmo:PX_profession rdfs:subPropertyOf crm:P107i_is_current_or_former_member_of .
This lets you search eg for "things produced by Italians" or "things produced by Sculptor-Medallists".

object/52176 has a complication: <[]> has nationality "British, active in Italy (1837-1839)". This is not 1 but 2 "nationalities", the second one temporary (only 2 years). This causes an invalid URL:
The URL can be fixed but that's not enough. If you model this as a single "nationality", you'd get too many unrelated "nationalities" and if you search by eg "American", you won't find the above person.

(-) So you must break this up. Options:
# Nationality plus Activity
bmo:PX_nationality <thesauri/nationality/American>;
P14i_performed <person-institution/6436/activity>.
<person-institution/6436/activity> a E7_Activity;
P2_has_type <thesaurus/activity/active>;
P7_took_place_at <place/Italy>;
P4_has_time-span <person-institution/6436/activity/date>.
<person-institution/6436/activity/date> a E52_Time-Span;
P82a_begin_of_the_begin "1837"^^xsd:gYear;
P82b_end_of_the_end "1938""^^xsd:gYear.
Pro: most faithful modeling. Cons: won't let the user search by "creator from Italy" because this P14i_performed is not included in FR_created_by.
# Treat Temporary "Nationality" as Permanent:
bmo:PX_nationality <thesauri/nationality/American>, <thesauri/nationality/Italian>.
Pro: user can search by "creator from Italy".
Cons: Less faithful modeling, since the temporary "nationality" is represented the same way as the permanent nationality.
Cons: Requires Yale to correlate country of activity ("Italy") to nationality ("Italian")
# Discard Temporary "Nationality"
<person-institution/6436> bmo:PX_nationality <thesauri/nationality/American>.
Pro: easiest to implement
Cons: loses information

(+) &nbsp;Emmanuelle: solution #1 is the best one to implement for Yale data. &nbsp;"Creator from India" seems to imply that indeed the creator is Indian, which is not the case. &nbsp;An example is&nbsp;[|]. &nbsp;It is impossible to mistaken&nbsp;Thomas Daniell's hunting scene for the work of a native Indian artist.

h3. Birth Place

"Born in" should be mapped to E67_Birth - P7_took_place_at.

For E67 reuse the same URL (e.g. <person-institution/6046/birth>)

h3. Life Dates

(+) you don't have any date (P82_at_some_time_within) for <person-institution/142/birth/date>. This makes all the following statements useless, so kill them.
Lec: we now have P82

h3. Dates Variety

Lec: we have more variety in Person dates. Emmanuelle provided examples, Vlado provided Turtle code:
- Some institutions have documented dates of existence: Published by Advanced Graphics London, 1969-present in []
crm:P82b_end_of_the_end "1713"^^xsd:gYear
Emmanuelle: shouldn't it be crm:P82b_end_of_the_begin "1713"^^xsd:gYear rather?
- Damien Hirst, born 1965 in []
Skip all of these altogether:
crm:P82b_end_of_the_end "1713"^^xsd:gYear
(?) &nbsp;Emmanuelle: I am not sure where 1712 and 1713 come from? &nbsp;His&nbsp;crm:P82a_begin_of_the_begin should be&nbsp;1765 and his&nbsp;crm:P82b_end_of_the_end should be 1830.
- Print made by John Bruce, fl. 1826 in []
"Flourit" can be modeled as E7_Activity that the person P12i_was_present_at, see [BMX Issues#Person / Biographical Dates]
(?) Vlado: ok, but first consider the Turtle snippets above

(+) &nbsp;Emmanuelle: Lec, when there are values in&nbsp;earliestDate and latestDate they are mostly correct. &nbsp;The most common case is that&nbsp;earliestDate and latestDate do not carry any values and we only have the Display.

h3. Gender

(-) &nbsp;Gender terms are used with&nbsp;bmo:PX_gender (eg <[]>) but are not defined

h3. Person vs Group vs Institution

If you can distinguish in LIDO different kinds of Actors (Person/ Group (informal)/ Legal Body (institution)) then use specific subclasses and subprops. The number of dashes below shows class nesting:
| *Actor* | *Begin* | *begin prop* | *end* | *end prop* |
| *Actor* | *Begin* | *begin prop* | *end* | *end prop* |
| E39_Actor | E63_Beginning_of_Existence | P92i_was_brought_into_existence_by | E64_End_of_Existence | P93i_was_taken_out_of_existence_by |
| -E21_Person | -E67_Birth | P98i_was_born | -E69_Death | P100i_died_in |
| -E74_Group | -E66_Formation | P95i_was_formed_by | -E68_Dissolution | P99i_was_dissolved_by |
| --E40_Legal_Body | -E66_Formation | P95i_was_formed_by | -E68_Dissolution | P99i_was_dissolved_by |
| \-E21_Person | \-E67_Birth | P98i_was_born | \-E69_Death | P100i_died_in |
| \-E74_Group | \-E66_Formation | P95i_was_formed_by | \-E68_Dissolution | P99i_was_dissolved_by |
| \--E40_Legal_Body | \-E66_Formation | P95i_was_formed_by | \-E68_Dissolution | P99i_was_dissolved_by |
URLs: strictly speaking "/birth" and "/death" are correct only for E21_Person, but it's good enough to also use for other actors

eg []
#- As described in [#Deep Zoom Image], the JPEG2000 URL [] is unsuitable since it serves the whole image.
# (/) Using ODAI GUID:&nbsp;
#- for format/1,2,3,6
| format/3 | large | Screen large | 1920 | jpeg | |
| format/6 | print-lg | Print large | 3000 | tiff | |
| format/7 | JPEG2000 \\ | Zoom (JPEG 2000) | 4279 | jp2 | This is the max available size. We don't use this URL for annotation since it serves the whole [#Deep Zoom Image] |

h3. Deep Zoom Image
This URL doesn't return anything, but you can append parameters to get what you need.
- the tile URLs are of this form:
[,2048,1024,1024/\!256,256/0/native.jpg\|,2048,1024,1024/\!256,256/0/native.jpg|,2048,1024,1024/!256,256/0/native.jpg] [,2048,1024,1024/\!256,256/0/native.jpg|,2048,1024,1024/!256,256/0/native.jpg]
- If you request a non-existing GUID, you get "Error: No response from server []". Occasionally I get the same error for an existing GUID, but that is a temporary outage
- another client that also implements IIIF tiles is OpenSeadragon (and one can get sample code to implement the same):
Image Views are different photographs of the same painting, using different Flags.
Eg the lovely Miss Prue [] has 8 image views:
{html:script=^5005-images.html}{html} {html}

<td valign="top"><img src=""/><br/>cropped to image, recto, unframed<br/><a href="">Screen small</a> (205x249)<br/><a href="">Screen medium</a> (395x480)<br/><a href="">Screen large</a> (1580x1920)<br/><a href="">Print large</a> (2468x3000)<br/><a href="">Zoom (JPEG 2000)</a> (4492x5460)<br/>
<td valign="top"><img src=""/><br/>recto, unframed<br/><a href="">Screen small</a> (169x249)<br/><a href="">Screen medium</a> (325x480)<br/><a href="">Screen large</a> (1300x1920)<br/><a href="">Print small</a> (1016x1500)<br/><a href="">Print medium</a> (1422x2100)<br/><a href="">Print large</a> (2031x3000)<br/>
<td valign="top"><img src=""/><br/>framed, recto<br/><a href="">Screen small</a> (217x249)<br/><a href="">Screen medium</a> (418x480)<br/><a href="">Screen large</a> (1673x1920)<br/><a href="">Print small</a> (1307x1500)<br/><a href="">Print medium</a> (1830x2100)<br/><a href="">Print large</a> (2614x3000)<br/>
<td valign="top"><img src=""/><br/>framed, verso <br/><a href="">Screen small</a> (217x249)<br/><a href="">Screen medium</a> (418x480)<br/><a href="">Screen large</a> (1670x1920)<br/><a href="">Print small</a> (1305x1500)<br/><a href="">Print medium</a> (1826x2100)<br/><a href="">Print large</a> (2609x3000)<br/>
<td valign="top"><img src=""/><br/>detail, recto <br/><a href="">Screen small</a> (249x197)<br/><a href="">Screen medium</a> (480x380)<br/><a href="">Screen large</a> (1920x1519)<br/><a href="">Print small</a> (1500x1187)<br/><a href="">Print medium</a> (2100x1661)<br/><a href="">Print large</a> (3000x2373)<br/>
<td valign="top"><img src=""/><br/>Composite X-radiograph<br/><a href="">Screen small</a> (209x249)<br/><a href="">Screen medium</a> (404x480)<br/><a href="">Screen large</a> (1614x1920)<br/><a href="">Print large</a> (2522x3000)<br/><a href="">Zoom (JPEG 2000)</a> (8016x9534)<br/>
<td valign="top"><img src=""/><br/>cropped to image, recto, unframed<br/><a href="">Screen small</a> (206x249)<br/><a href="">Screen medium</a> (397x480)<br/><a href="">Screen large</a> (1589x1920)<br/><a href="">Print small</a> (1241x1500)<br/><a href="">Print medium</a> (1737x2100)<br/><a href="">Print large</a> (2482x3000)<br/>

RS should display something similar on the Related Images tab (but not laid out in such an ugly way): all views, one format as image, all formats as links. See [#Image Derivation] for the RDF data

Lec: these strings are not from a controlled thesaurus, so people can put anything.
Vlado: it still seems to me they are fairly consistent, so Yale could represent this by breaking on space and making a thesaurus:
For now I think it's enough to lump them in one thesaurus, eg:
Emmanuelle: What do I do for the following crm:P14_carried_out_by association codes? Do they become types or labels?
Vlado: These are all types of Production sub-events, because they pertain to the nature of the production process. See [BM Association Mapping v2#Produced By Specific Process] for the pattern:
- -AR-Artist-
- -AU-author-
- FB-finished by
- -FB-finished by-
- \-M-maker\-
- R-printer (printed by)
- PM-printmaker (print made by)
- Z-publisher (published by)
- TU-touched up by (print)
- \-R-printer (printed by)\-
- -PM-printmaker (print made by)-
- \-Z-publisher (published by)\-
- -TU-touched up by (print)-

BTW: if you have just 1 code, it would be nice to optimize and not create sub-events, but BM doesn't do that

Use [|]
| crm:P14_carried_out_by | *R* | printed by |
| crm:P14_carried_out_by | *Z* | published by |
| crm:P14_carried_out_by | *5* | Drawn by |
| crm:P14_carried_out_by | *P* | Painted by |
| crm:P14_carried_out_by | *M* | Made by |
These codes mean the same:
| crm:P14_carried_out_by | *PM* | print made by |
| crm:P14_carried_out_by | *TU* | touched up by |
| crm:P14_carried_out_by | *E* | Engraved by |
| crm:P14_carried_out_by | *AQ* | Aquatinted by |
| crm:P14_carried_out_by | *VEB* | Variously engraved by |
| crm:P14_carried_out_by | *EB* | engravings by |

h3. Formerly Attributed To

See [BM Association Mapping v2#Probably/Unlikely Produced By]
- (?) What other lido:attributionQualifierActor have you got?
- (+) &nbsp;Emmanuelle: these are YCBA attribution qualifiers (also documented in&nbsp;[;../../../../../../../../../../display/ResearchSpace/Meta-Thesaurus+and+FR+Names&#124;&#124;&#124;&#124;&#124;&#124;&#124;&#124;&#124;&#124;&#124;&#124;&#124;&#124;&#124;&#124;&#124;&#124;&#124;&#124;&#124;&#124;&#124;&#124;&#124;&#124;&#124;&#124;&#124;&#124;&#124;\||]&nbsp;as&nbsp;[|]):&nbsp;Attributed to, Formerly, Formerly attributed to, After, Follower of, Imitator of, Style of, Circle of, Studio of, Workshop of

h3. Production Qualification

Look in [LIDO:29334|]. Search for "Object related role": there are 2 actors and a qualification:
| *Actor* | *Role* | *Qualification* |
| Samuel Palmer | Printmaker | Print made by |
| Alfred Herbert Palmer | Printmaker | completed by |

As you see in [BM Association Mapping v2#Produced By Specific Process], BM models "Printmaker" as a production sub-event with P2_has_type <printing> and P14_carried_out_by <actor>. They don't have a Qualification as you have above.
- Emmanuelle: I thought BM was using Qualifications as well? &nbsp;Here a BM record with "Drawn by Elizabeth Emily Murray":
- Vladimir: see the data at
I think the relevant production fact is
and it says that Emily Ruskin carried out a Production with P2_has_type <thesauri/production/drawing>.
No qualification whether she started, completed, or whatever

You have 2 options:
# Further split up the production type <thesaurus/technique/printmaker> into <thesaurus/technique/printmaker/print_made_by> and <thesaurus/technique/printmaker/completed_by>.
#- This is not faithful because "completed by" is not related in any way to printing. It's about who started something and who finished it, a pattern that can apply to any production technique (e.g. someone made a cast and another made the final sculpture from it).
#- Emmanuelle: I beg to differ. &nbsp;In this case what is implied for Alfred Palmer when his name is prefaced with 'completed by' is that we suspect that he etched and printed the plate. &nbsp;This is a case where further research will precisely identify his role, which in turn will change his roles and qualifications. &nbsp;Regardless of Alfred Palmer's role, however, it absolutely has to do with printing. &nbsp;
#- Vladimir: What I mean is that "completing" something is applicable not just for Printing, but for other processes as well (eg making a sculpture from a cast).
If you use "completed by" only for Printing, then you should call it "Print completed by" to be more specific.
# (-) Model the Qualification as a [Reified Association|BM Association Mapping v2#Translated Code In Reified Association]. An example application of this pattern is [production attribution (probably/unlikely)|BM Association Mapping v2#Probably/Unlikely Produced By].
<prod> P9_consists_of <prod/1>,<prod/2>.
<prod/1> P14_carried_out_by <SamuelPalmer>; P2_has_type <thesaurus/technique/printmaker>.
<prod/1/association> a bmo:EX_Association;
P140_assigned_attribute_to <prod/1>; P141_assigned <SamuelPalmer>; bmo:PX_property P14_carried_out_by;
P2_has_type <thesaurus/qualification/made_by>.
<prod/2> P14_carried_out_by <AlfredHerbertPalmer>; P2_has_type <thesaurus/technique/printmaker>.
<prod/2/association> a bmo:EX_Association;
P140_assigned_attribute_to <prod/2>; P141_assigned <AlfredHerbertPalmer>; bmo:PX_property P14_carried_out_by;
P2_has_type <thesaurus/qualification/completed_by>.
#- Emmanuelle: I have no objections against Reified Association but it seems given the&nbsp;(-) &nbsp;before it that you/Vladimir already decided against it?
#- Vladimir: everywhere in this page, the red minus means Yale should do something (and change it to a green plus)

| CB: commenced by |
| CPB:&nbsp;completed by |
| FB:&nbsp;finished by |

h3. Probably/Unlikely Produced By

* *Probably*

*A*: Attributed to

*PA*: Print attributed to

*&nbsp; &nbsp; &nbsp;* *AO*: attributed to office of

*&nbsp; &nbsp; &nbsp;* *PR*: perhaps

*&nbsp; &nbsp; &nbsp;* *PRB*: perhaps by

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; *PRA*: perhaps with assistance from

*&nbsp; &nbsp; &nbsp;*{*}PO*: possibly

*&nbsp; &nbsp; &nbsp;*{*}POB*: possibly by

*&nbsp; &nbsp; &nbsp;* *OPO*: or possibly

*&nbsp; &nbsp;* *COPO*: Circle of or possibly
* *Unlikely*

*AE*: Formerly attributed to:&nbsp;

h3. Use P14_carried_out_by and thesaurus/likelihood

h3. Influenced By

(-) "After" (and other similar codes) should be mapped to P15_was_influenced_by, with EX_Association and P2 code that says "after". See [BM Association Mapping v2#Influenced By] or Dominic’s document sec 6.6.16. Jana checked the document: a separate Production node is used in this case.

The current representation uses P14_carried_out_by for both "created" and "after" which is incorrect:
<> a crm:E12_Production ;
crm:P9_consists_of <> , <> .

<> a crm:E12_Production ;
crm:P14_carried_out_by <> ;
crm:P2_has_type <> ;
crm:P4_has_time-span <> .

<> a crm:E12_Production ;
crm:P14_carried_out_by <> ;
crm:P2_has_type <> .

Use P15_was_influenced_by

*AT*: After

*ATPO*: After possibly

*POAT*: possibly after

*ATPOB*: after possibly based on a model by

*AF*:&nbsp;follower of

*AI*: imitator of

*AL*: Manner/style of

h2. Production Authority

h3. Production Motivated By

*CO*: Commissioner

h2. Unknown Artist
{status:title=postponed|color=gray} Some records say "production performed by Unknown Artist".
- Vladimir: As for "18th century": RS cannot currently search by dates of the creator (life and flourit), but it can search by creation dates, which I think is "close enough".

Example: object/34466 is created "by unknown artist, 19th c.; after unknown artist."
In the current representation this maps to two production events using a single YCBA term. This is logically inconsistent (Unknown has influenced himself ;-) ):
- P14_carried_out_by <person-institution/616> and also
- P15_was_influenced_by the same <person-institution/616>

h3. Unknown Artist example

Jana: These statements don't carry information and the birth/date dates are even wrong.
<> a crm:E21_Person , skos:Concept ;
skos:inScheme ycba:person-institution ;
skos:altLabel "Unknown artist" ;
skos:prefLabel "unknown artist" ;
skos:altLabel "Unknown framemaker" , "Unknown rights holder" , "Unknown rights administrator" ;
crm:P98i_was_born <> ;
crm:P100i_died_in <> ;
bmo:PX_gender <> .
<> a crm:E67_Birth ;
crm:P82_at_some_time_within <> .
<> a crm:E52_Time-Span ;
rdfs:label "0" ;
crm:P82a_begin_of_the_begin "0"^^xsd:gYear .
<> a crm:E69_Death ;
crm:P82_at_some_time_within <> .
<> a crm:E52_Time-Span ;
rdfs:label "0" ;
crm:P82b_end_of_the_end "0"^^xsd:gYear .

Emmanuelle: Sorry to come back to this 'unknown' issue but if we don't emit 'unknown' creators as a group then works such as 4533 seem to have no creators since it is:
bmo:PX_display_wrap "Production by :: unknown artist" , "Production by :: After unknown artist"
This seems more wrong to me than modeling 'unknown' as a group?

Vlado: Not stating any facts about creators merely means that you don't know. It doesn't mean you assert there were no creators, due to semweb's Open World Assumption.
- Asserting that a single Unknown person created all these paintings is factually incorrect.
- Asserting he was born at year 0 is historically incorrect
Even if there was a year 0: I think that "0"^^xsd:gYear is invalid and will fail RDF validation.
- Asserting that he was influenced by (created them "After") himself is logically inconsistent.
- Asserting his gender is "unknown" is useless.

If you omit all these statements, you'd lose nothing, but gain correctness.

You and Ken described valid search use cases (see [#Closely Related Group], and we've postponed how to serve them.

Getty does have a bunch of unknown artists of *known* Nationality (e.g. Unknown Afghan).
But it's better to make a straightforward statement, and then you'd be able to search by nationality:
<object/4533/production> P14_carried_out_by <thesaurus/nationality/Afghan>.

h3. Closely Related Group

- Vlado: The simplest solution could be to just mark with a flag "there's significant unknown info about the producer".

*Closely Related Group association codes:*

AG; studio of
W: workshop of
AJ: circle of

*Produced by Closely Related Individual:*

N: Pupil of

h2. Curatorial Comment

- (-) Yale: PX_curatorial_comment needs date and author added to the data model
- {jira:RS-1926}
- Vlado: easy to tackle with EX_Association, which is is a subclass of E13_Attribute_Assignment (see [attribute_assignment@crmg] and [recorder@crmg]):
P14_carried_out_by <researcher>;
P4_has_time-span <obj/comment/1/date>.
<obj/comment/1/date> P82_at_some_time_within "2013-07-06"^^xsd:gYear. "2013-07-06"^^xsd:date.
-- you could alternatively use P3_has_note instead of PX_curatorial_comment, to accommodate apps that know CRM and EX_Association but not PX_curatorial_comment. But I still think using the subproperty is better

- Obviously in P141 you need to put the actual PX_curatorial_comment string, not the word "comment".
- Use a XSD type that corresponds to the date's resolution:
P82_at_some_time_within "2007-01"^^xsd:gYear : should use gYearMonth

h2. Inscriptions

- (?) Emmanuelle: Two other similar fields are problematic in our data: Signed and Inscriptions.&nbsp; They are problematic because, on the model of the marks field above, they record both the transcriptions of the signatures and inscriptions as well as the fact that we may have searched for a signature and inscription on a work but did not find any and consequently these fields may carry the value: not signed, not dated, no inscription.
The variations on these 3 values are multiple, unfortunately (not inscribed,…)&nbsp; In order to not emit administrative data about signatures and inscriptions (not signed, not dated, no inscription), we would need to filter out all of these variations
-- Vlado: I see the difficulty. Ok, let's not do such filtering, and just emit the strings as they are. (Semweb says not to record missing facts, but here you've recorded the fact that you searched for it and none was found)
h2. Dimensions


You state object dimensions (including their properties):
- (?) If you have data with lido:qualifierMeasurements, we should also consider it
- (-) I &nbsp;I assume "Support (PTG)" is a (semi-)controlled value, so better make a term:
The scheme is defined in [Meta-Thesaurus|#Meta-Thesaurus].

(-) &nbsp;Periods are complex cultural phenomena that may have time and place dimensions, even a union of such dimensions (think of Fascism). These are not Periods, they are mere Time-Spans:&nbsp;16th century, 17th century, 18th century, 16th century-17th century.

h2. Material and Technique

h2. Object Type and Genre

&nbsp;(+) &nbsp;resolved issue

(-) Object Type and Genre (lido:objectWorkType) are missing, eg
Which leaves me a bit puzzled how to map "classification": object type or "sub-collection".
- I wrote a little script to extract these 2 fields from Yale data:
{code:bash} egrep -A1 'type="(Classification|Object name)"' * | perl -pe "s{.*edu_(\d+).*?>([^<]*)(<.*)?}{$1: $2}" {code}
- For many Yale objects, objectWorkType and classification are the same (painting, scuplture, frame, etc)
- For some objects (4 of 13) there are differences: