compared with
Key
This line was removed.
This word was removed. This word was added.
This line was added.

Changes (123)

View Page History

h2. Getting Yale On-board

Lec: If there is something else you need to get this to work with Research Space please let me know
Vlado: Once it's compliant, we should:
- create RForms for your objects

See [RS Plan 3.7#Get Yale on-board with ResearchSpace|RS Plan 3.7#Get Yale on-board with ResearchSpace] for details. As of 08-Jul-2013, this iteration is under planning and the exact scope and start is not clear. I think we can get Yale on board before mid-Sep (the Getty meeting), but it depends on the exact scope.

It appears that Yale is *not* the bottleneck: starting the RS3.7 iteration is. So please let's not rush this review process\!

h2. Legend

Please don't use color or strikethrough, use the following symbols for easier tracking (easiest to edit them in Wiki Markup mode):
- (-) open issue

h2. Eyeball

Lec: I am reviewing for any typos, missing types...


h1. General Problems

- (+) STRONGLY Suggest to have 1 URI per object, not 3 sameAs URIs
Lec: BM has multiple, followed their lead
Vlado: this is *high priority* since RS cannot work with 3 sameAs URLs. And there's no good reason to publish your objects under 3 URLs: please explain why you want to do this
- (+) don't emit prefixes you don't need: lccn, oclc, ycba_aat, etc etc
- (+) crm:PX_\* (e.g. crm:PX_display_wrap) is wrong, should be bmo:PX_\*
Lec: fixed with [http://collection.britishart.yale.edu/id/ontology/PX_display_wrap]
Vlado: Please use bmo:PX_\* and not ycba:PX_*: don't create a second property with the same purpose.
- (+) Same holds about classes: use bmo:EX_Association not ycba:EX_Association: don't define your own class for the same purpose.

h2. Pubby

These issues are not about the mapping, but how RDF is presented by Pubby.
If you switch to Forest / OwlimWorkbench, they'll go away (and probably be replaced by different issues ;-) )

- (-) {status:title=low prio|color=gray} Pubby prefixes are not setup: shows "?:..."

h3. Link to download Turtle file

I'm now getting actual RDF and Turtle files for the sample set on box.com.


h3. Inverse links considered harmful

(?) I cannot examine a URI like [http://collection.britishart.yale.edu/id/page/thesauri/department] because pubby tries to show "is P51_current_keeper *of*" all objects and that takes forever.
Is there a way to switch these inverse links off?
{status:title=postponed|color=blue}
Currently you emit thesaurus data together with the object, and only the terms used in the object:
- This way you miss Broader terms, so eg a search for "Animal" or "Mammal" won't find [FR Transitivity]
-- Lec: regarding Places, why don't we use Geographic Coordinates (included by Yale) and search by a bounding box?
-- Vlado: RS currently doesn't have bounding box search, because BM Places thesaurus doesn't include Geographic Coordinates.

h2. Thesaurus Requirements

You must comply with [BMX Issues#Thesaurus requirements]
Each term should be both a CRM entity of appropriate type, and skos:Concept.

h3. Meta-Thesaurus
(-) Each thesaurus (ConceptScheme) used by Yale should be described in [Meta-Thesaurus and FR Names#YCBA Thesauri] (this section will be merged to the rest of the table)

(-) 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)

This applies to both Getty and YCBA local thesauri.
- {status:title=future|color=blue} extend RS to handle AAT as one ConceptScheme that includes a number of facets (hierarchies) for object type, material, technique, etc
-- (-) 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)
{noformat}
aat:230058 a skos:Concept; skos:prefLabel "oil gilding";
skos:inScheme <yale/thes/technique>.
{noformat}

Emmanuelle: It would be helpful to briefly go over the definitions for searchable and tagable.
- Searchable is a thesaurus that can be used in FR search. The list of FRs is [Meta-Thesaurus and FR Names#FR Names Table|Meta-Thesaurus and FR Names#FR Names Table] and the detailed definitions are [FR Implementation]. Examples:
-- BM Object is searchable using FR2_has_type "is/has/about" because it's mapped to P2_has_type of the object
-- BM Ware and BM Currency are searchable using the same FR because they are sub-properties of P2_has_type

h2. Term Distribution

- Yale: 99% of Yale terms come from TGN, AAT, and ULAN.
1% of terms come from ODNB, IconClass, YCBA Local terms (Frames, ...)
-- Vlado: such "local heros" are a typical pattern for any museum. BM People also has "local heros" that are not found in ULAN.
- Lec: will it be helpful if we make connections to ODNB, VIAF, DBPedia?
-- Vlado: yes, assuming you can easily export such term data according to [#Thesaurus Requirements]. If you source it from these external sources, you'd need to make the same SKOS & CRM mapping as for the rest, and register in the [Meta-Thesaurus|#Meta-Thesaurus].
If these are indeed less than 1%, I'd source them from a single thesaurus YCBA Local.


h2. Term Code Discrepancy

Your LIDO has some AAT codes that are truncated compared to the original. Eg object/7:
{code:xml}

h2. Local Terms

(-) don't export a term as "-1", eg [http://collection.britishart.yale.edu/id/thesauri/AAT/-1]
- Lec: Emmanuelle, please have some students go through TMS, I exclude now anything that has \-1

h2. Agents

- (+) remove crm:E55_Type: a Group is *not* a Type
{noformat}<thesauri/nationality/British> a crm:E55_Type , crm:E74_Group , skos:Concept ;{noformat}

h2. Thesaurus URIs

- (+) Use more logical URIs that reflect the nature of the resource or type, and don't reflect their genesis in existing systems:
{noformat}

h2. Exhibition URIs

- (+) We need to make decision on URI for exhibition, originally we had a short identifier, BM suggested title, this does not always work well, eg see: ObjectID 34
- Vlado: Yes, pretty long titles in [http://collection.britishart.yale.edu/id/page/object/34].

h3. Getty URIs

- Don't use YCBA-specific URIs for Getty, eg
[http://collection.britishart.yale.edu/id/thesauri/ULAN/500303557]

h2. Bibliography

- (-) Page numbers, eg for [http://collection.britishart.yale.edu/id/bibliography/2775]
- Vlado: BM uses [BIBO|http://bibotools.googlecode.com/svn/bibo-ontology/trunk/doc/index.html], for example see [http://test.researchspace.org:8081/resource?uri=http://collection.britishmuseum.org/id/bibliography/148].

h3. Title Types

- Why do you need these duplicate types?
{noformat}crm:P2_has_type <thesaurus/title/Alternate-title> , <thesaurus/title/alternate> .{noformat}

h3. Duplicate Titles

- (-) these two titles are duplicated. Keep just one of them: I suggest <title/1> for uniformity with the alternate title(s)
{noformat}

h3. Title Language

- (optional) Indicate the title language:
{noformat}
{noformat}
- Emmanuelle: we indicate the language of the titles only if they are in foreign language <thesaurus/title/ForeignLanguage-title>, and probably not consistently. All the other titles are understood as being in American English, the official language of the YCBA.
- (-) Vladimir: fair enough\! So indicate language only for that type, and say it's translation of the Preferred one:
{noformat}
<object/19850/title/N> a E35_Title;

h2. Related Resources

List all URLs closely related to the object: web pages, LIDO XML, etc.
Eg for [http://collection.britishart.yale.edu/id/object/5005] "Mrs. Abington as Miss Prue in Love for Love by William Congreve" this includes:

h3. Representing Related Resources

An important question is how to represent these related resources and how to link them to the object. CRM doesn't have specific classes for "web page" or "XML record" but E31_Document is appropriate: "identifiable immaterial items that make propositions about reality. These propositions may be expressed in text, graphics, images, audiograms, videograms or by other similar means. Documentation databases are regarded as a special case of E31 Document." (Therefore a single XML record is also E31_Document). See [document_references@crmg], [reference@crmg]

<http://discover.odai.yale.edu/ydc/Record/1669236>,
<http://www.google.com/culturalinstitute/asset-viewer/mrs-abington-as-miss-prue-in-love-for-love-by-william-congreve/tQHBb0Q2MZF2uQ>.
<http://collections.britishart.yale.edu/vufind/Record/1669236>
a E31_Document; dc:format "text/html"; P2_has_type <thes/document/home-page>.
<http://collections.britishart.yale.edu/oaicatmuseum/OAIHandler?verb=GetRecord&identifier=oai:tms.ycba.yale.edu:7&metadataPrefix=lido>

h3. Image Metadata

Yale keeps numerous image assets, and Yale ODAI provides extensive metadata about the images:
- documentation: [https://docs.google.com/document/d/1rfUHjy_YvVC5fSIsB4aCi5-t2ZhNYrDui-L9EEXXm9g/edit]

Description: I haven't read the documentation but here's what I see.
| *path/field* | *eg* | *description* |
| X/derivatives/Y | | X ranges over [#Image Views] (0..M, 0 is Main View), Y ranges over [#Image Sizes] (1,2,3,6,7) |
| ./formatId | 1 | size id |
| ./formatShort | sm | size name |
| ./label | Screen small | size label |
| ./url | [http://deliver.odai.yale.edu/content/id/482f519c-eebf-4596-819c-4c8197c4d3e5/format/1] | logical URL (request this) |
| *path/field* | *eg* | *description* |
| X/derivatives/Y | | X ranges over [#Image Views] (0..M, 0 is Main View), Y ranges over [#Image Sizes] (1,2,3,6,7) |
| ./formatId | 1 | size id |
| ./formatShort | sm | size name |
| ./label | Screen small | size label |
| ./url | [http://deliver.odai.yale.edu/content/id/482f519c-eebf-4596-819c-4c8197c4d3e5/format/1] | logical URL (request this) |
| ./source | [http://b02.deliver.odai.yale.edu/48/2f/482f519c-eebf-4596-819c-4c8197c4d3e5/ba-obj-7-0001-pub-sm.jpg] | physical URL (redirects to it) |
| ./bucketDNS | b02.deliver.odai.yale.edu | physical server |
| ./bucketName | b02.deliver.odai.yale.edu | physical server |
| ./bucketPath | 48/2f/482f519c-eebf-4596-819c-4c8197c4d3e5/ba-obj-7-0001-pub-sm.jpg | physical path |
| ./contentId | 482f519c-eebf-4596-819c-4c8197c4d3e5 | GUID |
| ./filename | ba-obj-7-0001-pub-sm.jpg | file name |
| ./unitAccessOnly | false | Only the Yale unit that created the image should have access |
| ./cas | false | Login through CAS is required (campus-only access) |
| ./captcha | false | protected by captcha? Only size 5 are |
| ./format | image/jpeg | image format |
| ./sizeBytes | 33169 | file size |
| ./pixelsX | 249 | width |
| ./pixelsY | 186 | height |
| X/metadata | | describes Image View X |
| ./caption | cropped to image, recto, unframed | enumerates Flags of the Image View |
| ./source | Yale Center for British Art | credits |
| ./imageCredit | Digital Image: Yale Center for British Art | credits |
| ./webStatement | [http://hdl.handle.net/10079/gb5mkww] | redirects to [http://britishart.yale.edu/collections/using-collections/image-use] |
| ./usageTerms | [http://hdl.handle.net/10079/gb5mkww] | always same(?) |
| ./imageCopyrightNotice | | always(?) empty |
| ./imageCopyrightMarked | false | always(?) false |
| ./assetId | d70ae2b604a64bd24809441a5d24233a8d406925 | another GUID |
| X/contentId | 482f519c-eebf-4596-819c-4c8197c4d3e5 | GUID, same as above |
| ./bucketDNS | b02.deliver.odai.yale.edu | physical server |
| ./bucketName | b02.deliver.odai.yale.edu | physical server |
| ./bucketPath | 48/2f/482f519c-eebf-4596-819c-4c8197c4d3e5/ba-obj-7-0001-pub-sm.jpg | physical path |
| ./contentId | 482f519c-eebf-4596-819c-4c8197c4d3e5 | GUID |
| ./filename | ba-obj-7-0001-pub-sm.jpg | file name |
| ./unitAccessOnly | false | Only the Yale unit that created the image should have access |
| ./cas | false | Login through CAS is required (campus-only access) |
| ./captcha | false | protected by captcha? Only size 5 are |
| ./format | image/jpeg | image format |
| ./sizeBytes | 33169 | file size |
| ./pixelsX | 249 | width |
| ./pixelsY | 186 | height |
| X/metadata | | describes Image View X |
| ./caption | cropped to image, recto, unframed | enumerates Flags of the Image View |
| ./source | Yale Center for British Art | credits |
| ./imageCredit | Digital Image: Yale Center for British Art | credits |
| ./webStatement | [http://hdl.handle.net/10079/gb5mkww] | redirects to [http://britishart.yale.edu/collections/using-collections/image-use] |
| ./usageTerms | [http://hdl.handle.net/10079/gb5mkww] | always same(?) |
| ./imageCopyrightNotice | | always(?) empty |
| ./imageCopyrightMarked | false | always(?) false |
| ./assetId | d70ae2b604a64bd24809441a5d24233a8d406925 | another GUID |
| X/contentId | 482f519c-eebf-4596-819c-4c8197c4d3e5 | GUID, same as above |

Questions:

h3. Image URLs

ODAI has several URLs that redirect to the physical URL:
# (x) Using object id:
{noformat}http://scale.ydc2.yale.edu/iiif/<contentId>{noformat}

| *image alias* | *format* | *URL* |
| view0/format1 | sm | [http://deliver.odai.yale.edu/content/id/482f519c-eebf-4596-819c-4c8197c4d3e5/format/1] |
| view0/format2 | med | [http://deliver.odai.yale.edu/content/id/482f519c-eebf-4596-819c-4c8197c4d3e5/format/2] |
| view0/format3 | large | [http://deliver.odai.yale.edu/content/id/482f519c-eebf-4596-819c-4c8197c4d3e5/format/3] |
| view0/format6 | print-lg | [http://deliver.odai.yale.edu/content/id/482f519c-eebf-4596-819c-4c8197c4d3e5/format/6] |
| view0/format7 | JPEG2000 | [http://scale.ydc2.yale.edu/iiif/482f519c-eebf-4596-819c-4c8197c4d3e5] |
| view1/format1 | sm | [http://deliver.odai.yale.edu/content/id/279ce6c0-c584-43e4-a5b4-5af2c90b82a0/format/1] |
| view1/format2 | med | [http://deliver.odai.yale.edu/content/id/279ce6c0-c584-43e4-a5b4-5af2c90b82a0/format/2] |
| view1/format3 | large | [http://deliver.odai.yale.edu/content/id/279ce6c0-c584-43e4-a5b4-5af2c90b82a0/format/3] |
| view1/format6 | print-lg | [http://deliver.odai.yale.edu/content/id/279ce6c0-c584-43e4-a5b4-5af2c90b82a0/format/6] |
| view1/format7 | JPEG2000 | [http://scale.ydc2.yale.edu/iiif/279ce6c0-c584-43e4-a5b4-5af2c90b82a0] |

In the sections below we use these image aliases for brevity. In RDF the actual http URL should be used. *Not* a "made up" node with P1_is_identified_by pointing to the actual URL

h3. Image Sizes

YCBA keeps images in many sizes. These sizes or "formats" are over 15 and include video, 3D models, etc.
The ones I've encountered for images are listed below ("width" is just an example):
| *url suffix* | *size label* | *width* | *file* | *use in RS* |
| format/1 | Screen small | 250 | jpeg | result list thumbnail (or could use 2) |
| format/2 | Screen medium | 480 | jpeg | lightbox, object view, data basket preview |
| format/3 | Screen large | 1920 | jpeg | |
| format/6 | Print large | 3000 | tiff | |
| format/7 | 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] |
| format/1 | Screen small | 250 | jpeg | result list thumbnail (or could use 2) |
| format/2 | Screen medium | 480 | jpeg | lightbox, object view, data basket preview |
| format/3 | Screen large | 1920 | jpeg | |
| format/6 | Print large | 3000 | tiff | |
| format/7 | 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

Many YCBA objects have Deep Zoom images (JPEG2000), sometimes even several per object.
Eg Miss Prue [http://collections.britishart.yale.edu/vufind/Record/1669236] has:
This URL doesn't return anything, but you can append parameters to get what you need.
- the tile URLs are of this form:
[http://scale.ydc2.yale.edu/iiif/1b747e8f-7754-482c-b5a2-9e1dc1986f4b/0,2048,1024,1024/\!256,256/0/native.jpg|http://scale.ydc2.yale.edu/iiif/1b747e8f-7754-482c-b5a2-9e1dc1986f4b/0,2048,1024,1024/!256,256/0/native.jpg]
- If you request a non-existing GUID, you get "Error: No response from server [http://scale.ydc2.yale.edu/iiif]". 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):
[http://openseadragon.github.io/examples/tilesource-iiif/]

h3. Image Views

Image Views are different photographs of the same painting, using different modes (Flags).
Eg the lovely Miss Prue [http://collections.britishart.yale.edu/vufind/Record/1669236] has 8 image views:

h3. Image Flags

The views have these comma-separated Flags:
0. cropped to image, recto, unframed (0 is always the Main View)

h3. Image Rights

YCBA doesn't claim copyright over any images, so we only need to point to a policy page.
See [#Object Rights] for a more substantial discussion of public domain over copyrighted objects.

h3. Image Representation

(See image aliases in the [#Image URLs] table)
- (-) The correct properties to use are:

h3. Image Derivation

We connect only format2 directly to the object (PX_has_main_representation or P138i) and declare all formats derivatives thereof (P130i).
This is a trick required by RS, so it can show only one format on screen, and provide links for the rest (as in [#Image Views]):

h3. Image Creation

- (-) this is wrong
{noformat}

h3. Image RDF

Tying it all together, this section defines the RDF mapping for images.
- The first image view is the Main representation

- (-) Shorten the URL a bit:
-- in this URL: <[http://collection.britishart.yale.edu/id/object/482f519c-eebf-4596-819c-4c8197c4d3e5/image/creation]>
-- the image URL is: <[http://collection.britishart.yale.edu/id/object/482f519c-eebf-4596-819c-4c8197c4d3e5]>
-- so you don't need to append "/image" to it, use <[http://collection.britishart.yale.edu/id/object/482f519c-eebf-4596-819c-4c8197c4d3e5/creation]>

h2. Depiction

Couple issues here:
{noformat}

h2. IconClass

See [IconClass#IconClass Use at YCBA]:
- (-) Emit P129 for each use

h2. Acquisition

- (+) The YCBA director does not want to publish which person gave up the object.
Emmanuelle: Right now, we absolutely cannot publish who were the previous owners of our objects, no matter if they have passed or not.

h3. YCBA sub-orgs

- (?) The acquisition label (and the [Credit Line facet here|http://collections.britishart.yale.edu/vufind/Search/Results?join=AND&lookfor0%5B%5D=&type0%5B%5D=allfields&bool0%5B%5D=AND&lookfor1%5B%5D=&type1%5B%5D=title&bool1%5B%5D=AND&lookfor2%5B%5D=&type2%5B%5D=auth_author&bool2%5B%5D=AND&lookfor3%5B%5D=&type3%5B%5D=earliestDate&bool3%5B%5D=AND&lookfor4%5B%5D=&type4%5B%5D=topic&bool4%5B%5D=AND&lookfor5%5B%5D=&type5%5B%5D=geographic&bool5%5B%5D=AND]) show that there are several "sub-orgs" (or sub-collections) under it: Paul Mellon Collection, Paul Mellon Fund, Gift of Mr. and Mrs. J. Richardson Dilworth, B.A. 1938, etc.
If it's important to preserve this information in RDF, you could create sub-agents under YCBA, eg like this:

h2. Current Owner, Keeper

- (-) If YCBA is incorporated, use E40_Legal_Body instead of the more generic E74_Group:
{noformat} <thesauri/ULAN/500303557> a crm:E74_Group , skos:Concept ;

h2. Current Location

You currently use per-object place representations. Such places are not searchable since they're not in a thesaurus.
{noformat}

h3. Public Domain

The majority of works in YCBA's collection are in the Public Domain. For example:
- view: [http://collections.britishart.yale.edu/vufind/Record/1669236]

h3. Copyrighted

There are some objects that are copyrighted. Let's consider one:
- view: [http://collections.britishart.yale.edu/vufind/Record/1669290]

h2. Production

When and why to use {nf} <obj/production/M/association> a ycba:EX_Association {nf}
That's defined by the specific sections in [BM Association Mapping v2]. The Intro section describes 3 patterns: code in Event, code in Subevent, code in Association, and the specific sections say which to use for which part of your data

h3. Produced By Specific Process

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:

h3. Formerly Attributed To

object/7: "Formerly attributed to Benjamin Williams Leader" is mapped without any mention of "Formerly attributed":
{noformat}
{noformat}

- (-) Qualify Production with an EX_Association having type <thes/likelihood/formerly-attributed>.
See [BM Association Mapping v2#Probably/Unlikely Produced By]
- (?) What other lido:attributionQualifierActor have you got?

h3. Closely Related Group

- Emmanuelle: I think it would make sense to model 'unknown artist' as a group because it is a denomination that actually contains many different entities (all unknown artists are not the same), and also because traditionally when we speak we create a short cut but we actually cannot be sure that 'unknown artist' is only one artist for a work of art.
-- The National Gallery has grappled with this as well and models 'Unknown Artist' as a sub-group of E74: [http://research.ng-london.org.uk/wiki/index.php/Category:EN41-Artist_Sub_Group]:
-- Vlado: That's ok for this search case, as used by a person. But still there's a falsehood in the RDF, that all these paintings are by the same person. If you want to e.g. investigate painting *similarity*, this will trip you up. IMHO to avoid spurious unification, an Unknown should not be a known term or URI. Could be a blank (URI-less) node, which is by definition unique.
- Emmanuelle: traditionally when we speak we create a short cut but we actually cannot be sure that 'unknown artist' is only one artist for a work of art.
-- Vlado: Exactly\!
- Vlado: seems to me there are different *degrees of unknown* that may need different modeling, e.g.:
-# [http://collection.britishart.yale.edu/id/page/object/7] has 2 records:
<object/7/production/3> crm:P14_carried_out_by <unknown> .
{noformat}
This says there were 2 painters, one is B.W.Leader and the other Unknown: which does not reflect the actual situation (there is 1 painter\!)
-# In another case there may be actual evidence of 2 producers (e.g. Rembrandt and someone unknown from his Workshop).
- Vlado: The simplest solution could be to just mark with a flag "there's significant unknown info about the producer".

h2. Curatorial Comment

- (-) Yale: PX_curatorial_comment needs date and author added to the data model
- Vlado: easy to tackle with EX_Association, which is is a subclass of E13_Attribute_Assignment (see [attribute_assignment@crmg] and [recorder@crmg]):

h2. Inscriptions

Please include TTL samples with Inscription info.
- [http://collections.britishart.yale.edu/vufind/Record/1670022]

h3. Marks

(-) Marks are different: unlike E34_Inscription, E37_Mark is not a subclass of E33_Linguistic_Object (see [cidoc_class_hierarchy@crmg]) so they should *not* include label/transcription.
Eg [object/14670|http://collections.britishart.yale.edu/oaicatmuseum/OAIHandler?verb=GetRecord&identifier=oai:tms.ycba.yale.edu:14670&metadataPrefix=lido] has LIDO:

h3. Not Marked

(-) "not marked" should be ignored (emit nothing), eg [object/41229|http://collections.britishart.yale.edu/oaicatmuseum/OAIHandler?verb=GetRecord&identifier=oai:tms.ycba.yale.edu:41229&metadataPrefix=lido]:
{code:xml}
{code}

- (?) 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)
- all Signed and Inscriptions values that do not contain “”.&nbsp; The double quotation marks are a sure sign that a transcription is recorded. &nbsp;Is it possible?
-- Vlado: I think that giving meaning to punctuation is too brittle: maybe some curators didn't use them, or used slightly different punctuation...
I say cancel this whole section

h2. Dimensions

You state object dimensions (including their properties):
{noformat}

h2. Period/Culture

This ain't mapped: object/7:
{code:xml}
{code}

Yale uses the field lido:culture and a term from the AAT Styles and Periods facet.
Previously we mapped BM's Period/Culture field to crm:E4_Period (see [BMX Issues#Specific CRM Constructs] and again [BMX Issues#Period/Culture]).
These are slightly different concepts but closely related, so the mapping is correct:
<object/7/production/1> crm:P10_falls_within aat:300111159.
aat:300111159 a skos:Concept, crm:E4_Period;
skos:inScheme aat: , aat_periods: ;
skos:prefLabel "British".
{noformat}
The scheme is defined in [Meta-Thesaurus|#Meta-Thesaurus].
Depending on a tech decision you may have to emit only aat_periods: and skip aat: )

h2. Material and Technique

lido:termMaterialsTech has 3 types:
- support (eg laid paper, wove paper, canvas)
{noformat}
<object/64421>
P45_consists_of
aat:300011914, # wood
aat:300264831. # gold leaf

h2. Object Type and Genre

(-) Object Type and Genre (lido:objectWorkType) are missing, eg
{code:xml}

- Note1: BM has defined subprops of P2_has_type: PX_object_type, PX_ware (for pottery), PX_escapement (for clocks). But so far I don't see a need to do this for YCBA
- Note2: don't be confused like me that "landscape" above means "painting in landscape orientation", which is a subtype (describes *is*\-ness of the object).
It means "a landscape is painted", as you can see in [Abstract Landscape (Dark Fir Shoreham II Morning)|http://collections.britishart.yale.edu/vufind/Record/1666154] which is in portrait orientation

h2. Collection

- (-) Indicate the collection for each object, see [collection@crmg]
{noformat}

h2. Classification

LIDO XML has a field <lido:classification> that's similar to <lido:objectWorkType>. LIDO defines them like this:
- objectWorkType: The specific kind of object / work being described.
- classification: Concepts used to categorize an object / work by grouping it together with others on the basis of similar characteristics. The category belongs to a systematic scheme (classification) which groups objects of similar characteristics according to uniform aspects. This grouping / classification may be done according to material, form, shape, function, region of origin, cultural context, or historical or stylistic period. In addition to this systematic grouping it may also be done according to organizational divisions within a museum (e.g., according to the collection structure of a museum).

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:sh} egrep -A1 'type="(Classification|Object name)"' * | perl -pe "s{.*edu_(\d+).*?>([^<]*)(<.*)?}{$1: $2}" {code}
{code:sh}{code}
- For many Yale objects, objectWorkType and classification are the same (painting, scuplture, frame, etc)
- For some objects (4 of 13) there are differences:
| *object* | *ObjectWorkType* | *classification* | *n* |
| 4005 | 999 No ObjectWorkType for Record | 300041273 Print | 1 |
| 15206 | 300033973 drawing; 300078925 watercolor | 300033973 Drawing & Watercolor | 2 |
| 19850 | 300033973 drawing | 300033973 Drawing & Watercolor | 3 |
| 21890 | 300041338 intaglio print | 300041273 Print | 4 |
| 57163 | 300255019 cake; 300047090 sculpture | 300047090 Sculpture | 5 |
| *object* | *ObjectWorkType* | *classification* | *n* |
| 4005 | 999 No ObjectWorkType for Record | 300041273 Print | 1 |
| 15206 | 300033973 drawing; 300078925 watercolor | 300033973 Drawing & Watercolor | 2 |
| 19850 | 300033973 drawing | 300033973 Drawing & Watercolor | 3 |
| 21890 | 300041338 intaglio print | 300041273 Print | 4 |
| 57163 | 300255019 cake; 300047090 sculpture | 300047090 Sculpture | 5 |

Analysis of the differences:
# and 5. Several ObjectWorkTypes, Classification reflects just one of them.
Perhaps Corresponds to interpreting Classification as "sub-collection".
# ObjectWorkType and Classification are the same, just that a different label "Drawing & Watercolor" has been used
(the official AAT label is "drawings (visual works)")
# ObjectWorkType is a sub-division of Classification.
Corresponds to interpreting Classification as "sub-collection"

As described in the prev section, none of these terms is connected to the object in RDF.

h1. Collections and Object Types

The above sections are written after examining a few Paintings only.
But YCBA has other object types (Prints, Drawings, Sculpture, Paintings, Frames, even Cakes\!), for which the mapping could be slightly different.
- (/) : collection that is out of scope for now
Eg see [MARC21|http://columbus.library.yale.edu:8055/OAI_Orbis/src/OAIOrbisTool.jsp?verb=GetRecord&identifier=oai:orbis.library.yale.edu:3505631&metadataPrefix=marc21] and [OAI_DC|http://columbus.library.yale.edu:8055/OAI_Orbis/src/OAIOrbisTool.jsp?verb=GetRecord&identifier=oai:orbis.library.yale.edu:3505631&metadataPrefix=oai_dc] records for a book
- (!) Lec to include various object types in the samples

{table-plus:columnTypes=S,I|autoTotal=true}
|*collection*|*count*|*search, | *collection* | *count* | *search, browse* |
| Paintings and Sculpture | 2226 |[search|http://britishart.yale.edu/collections/search/paintings-and-sculpture] [browse|http://collections.britishart.yale.edu/vufind/Search/Results?lookfor0%5B%5D="Paintings+and+Sculpture"&type0%5B%5D=collection_facet] |
| Prints and Drawings | 48968 |[search|http://britishart.yale.edu/collections/search/prints-and-drawings] [browse|http://collections.britishart.yale.edu/vufind/Search/Results?lookfor0%5B%5D="Prints+and+Drawings"&type0%5B%5D=collection_facet] |
| Paintings and Sculpture | 2226 | [search|http://britishart.yale.edu/collections/search/paintings-and-sculpture] [browse|http://collections.britishart.yale.edu/vufind/Search/Results?lookfor0%5B%5D="Paintings+and+Sculpture"&type0%5B%5D=collection_facet] |
| Prints and Drawings | 48968 | [search|http://britishart.yale.edu/collections/search/prints-and-drawings] [browse|http://collections.britishart.yale.edu/vufind/Search/Results?lookfor0%5B%5D="Prints+and+Drawings"&type0%5B%5D=collection_facet] |
| (/) Rare Books and Manuscripts | 15392 |[search|http://britishart.yale.edu/collections/search/rare-books-and-manuscripts] [browse|http://collections.britishart.yale.edu/vufind/Search/Results?lookfor0%5B%5D="Rare+Books+and+Manuscripts"&type0%5B%5D=collection_facet]| | [search|http://britishart.yale.edu/collections/search/rare-books-and-manuscripts] [browse|http://collections.britishart.yale.edu/vufind/Search/Results?lookfor0%5B%5D="Rare+Books+and+Manuscripts"&type0%5B%5D=collection_facet] |
| (/) Reference Library | 33173 | [search|http://britishart.yale.edu/collections/search/reference-library-and-archives] [browse|http://collections.britishart.yale.edu/vufind/Search/Results?lookfor0%5B%5D="Reference+Library"&type0%5B%5D=collection_facet] |
| Frames | 1376 |[search|http://britishart.yale.edu/collections/search/frames] [browse|http://collections.britishart.yale.edu/vufind/Search/Results?lookfor0%5B%5D="Frames"&type0%5B%5D=collection_facet] |
| Frames | 1376 | [search|http://britishart.yale.edu/collections/search/frames] [browse|http://collections.britishart.yale.edu/vufind/Search/Results?lookfor0%5B%5D="Frames"&type0%5B%5D=collection_facet] |
{table-plus}
The available Search fields and [#Classification] vary by collection

h2. Paintings and Sculpture

- Search fields:
Title:

h3. Cake

Interesting example: a cake: [VUFind|http://collections.britishart.yale.edu/vufind/Record/1670022], [LIDO|http://collections.britishart.yale.edu/oaicatmuseum/OAIHandler?verb=GetRecord&identifier=oai:tms.ycba.yale.edu:57163&metadataPrefix=lido]
- Object name: cake, sculpture
OK P62_depicts

h2. Prints and Drawings
Emmanuelle: Contemporary art always brings up challenging cataloguing and intellectual issues.
The cake titled 'Boots' is a 2001 work by&nbsp;Sarah Lucas, a contemporary British artist. &nbsp;It is effectively a cake with an inkjet portrait of the artist on it (think edible frosting\!) contained in a box.
Inside the box lies this rather intriguing inscription: "Cake (2001): a series of 12 iced fruit cakes with inkjet images. Each cake is an edition of 25. Produced by Cakes Direct, Ilford, Essex. This signed box certifies the authenticity of the artwork contained within. It must accompany the work through any changes of ownership. \| Edition number 20/25 \[hand written\] Date 2001\[hand written\]" The inscription is followed by the signature of the artist. &nbsp;So in fact the work of art 'Boots' is not only the cake, but the cake within the box. They cannot be separated. That is why we catalogued 'boxes (containers)' as a subject term.

{color:#000000}{*}Prints and Drawings{*}{color}
- Search fields:
Title:

h2. Frames

- search fields
Title: