Version 32 by lec.maj
on Jul 17, 2013 16:27.

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

Changes (136)

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:
- try loading the data
- load your thesauri. Complete Getty or only the subset used by your objects? How about Broader terms?
- implement Image Annotation over your DeepZoom images (we also use IIP Image for RKD images, so shouldn't be too hard) while you use IIIF)
- coreference some of your terms to enable cross-collection search
- 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...


h2. General

- (-) {status:title=low prio|color=gray} Pubby prefixes are not setup: shows "?:..."
Lec: does same for BM, will try to fix
Lec: BM has multiple, followed their lead
Vlado: RS currently cannot work with these sameAs (eg would return results in triplicate). BM puts sameAs in separate files that we don't load
Lec: we still need to figure this out (don't want to publish two data sets one for RS and one for the world) - not pressing low priority
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. Connected Resources

TODO Vlado: write down appropriate representations

It's best to list all URLs closely related to each object, eg
[http://collection.britishart.yale.edu/id/object/5005]
"Mrs. Abington as Miss Prue in Love for Love by William Congreve":
Short: [http://www.google.com/culturalinstitute/asset-viewer/tQHBb0Q2MZF2uQ]
Long: [http://www.google.com/culturalinstitute/asset-viewer/mrs-abington-as-miss-prue-in-love-for-love-by-william-congreve/tQHBb0Q2MZF2uQ]
- (/) Pubby page. I don't think we need it since
[http://collection.britishart.yale.edu/id/page/object/5005]

{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|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

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.

There will be a meeting at Getty in September 2013, with 1/2 day discussion on Vocabularies

h2. Agents
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
- Lec: Emmanuelle there are cases where subjects are TGN where conceptID = 0, I will try to ignore. Example ObjectID = 34
- Vlado: in chat Emmanuelle said "-1" come from Yale local terms. Then emit them as such, don't look them up in AAT

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}
skos:prefLabel "Robert Smirke I" , "Robert Smirke R. A." , "Robert Smirk" , "Robert I Smirke" , "Robert Smirke" ;
{noformat}
Lec: Awaiting Emmanuelle confirmation if subjectActor will have multiple names, currently not in LIDO
Emmanuelle: yes a fair number of our subjectActor have alternate names in addition to their preferred names.
- (+) 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 and are taking into account both person and groups

(+) Lec: we have more variety in Person dates. Emmanuelle to provide some more examples
- Some institutions have documented dates of existence: Published by Advanced Graphics London, 1969-present in [http://collection.britishart.yale.edu/id/page/object/48770]
- Creator that is an institution: Monro School (but no documented dates of existence in our system): [http://collection.britishart.yale.edu/id/page/object/5981]
- institution as Rights Administrator: Design and Artists Copyright Society in [http://collection.britishart.yale.edu/id/page/object/5054]
- Richard Wilson, 1712 or 1713-1782 in [http://collection.britishart.yale.edu/id/object/423]
- Damien Hirst, born 1965 in [http://collection.britishart.yale.edu/id/object/4908]
- John Samuel Agar, ca. 1770-after 1820 in [http://collection.britishart.yale.edu/id/page/object/26383]
- Print made by John Bruce, fl. 1826 in [http://collection.britishart.yale.edu/id/page/object/30564]


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

- (+) &nbsp;We (-) 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].
{noformat}
{noformat}
- RS doesn't care what the URI is
-* Lec: updated with standard ID based URI's&nbsp;

h3. Getty URIs

- Don't use YCBA-specific URIs for Getty, eg
[http://collection.britishart.yale.edu/id/thesauri/ULAN/500303557]
This won't let your data mesh with other data using Getty.
- (+) Use the official namespace that Getty just decided (20-Jun-2013)
[http://vocab.getty.edu]
Lec: ULAN, AAT, TGN converted to Getty URIs

h3. Title Types

- Why do you need these duplicate types?
{noformat}crm:P2_has_type <thesaurus/title/Alternate-title> , <thesaurus/title/alternate> .{noformat}
{noformat}crm:P2_has_type <thesaurus/title/Repository-title> , <thesaurus/title/preferred> .{noformat}
- Emmanuelle: the capitalized title types talk about the purpose of the titles, not their ranking. Here are all title types possible: Alternate, Collective, Creator's, Exhibited, Foreign language, Former, Inscribed, Repository, Verso.
- Emmanuelle: The lowercase title attributes (alternate and preferred) talk about the ranking/preference of the titles.
- Can an object have different Repository title and Preferred title?
Emmanuelle: no, all Repository titles are always the preferred ones. But the alternate titles are not all of the type Alternate.

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}
P72_has_language <thesaurus/language/english>.
{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. 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.
{noformat}

h3. Image Metadata

Yale keeps numerous image assets, and Yale ODAI provides extensive metadata about the images:
- documentation: [https://sites.google.com/a/odaiprojects.com/projects-site/home/content-delivery-service/cds-documentation/image-delivery-and-api]
-- 2 samples: [^7-image-info.xml] (2 views), [^5001-image-info.xml] (8 views)
- JSON: eg [http://deliver.odai.yale.edu/info/repository/YCBA/object/7/type/2?output=json]
-- slightly worse format (two extra parentheses):
[http://deliver.odai.yale.edu/info/repository/YCBA/object/7/type/2?output=jsonp&callback]
-- this sanitized version was in the RDF but is a broken link
-- 3 samples formatted with Emacs: [^7-image-info.json] (2 views), [^5005-image-info.json] (8 views), [^5054-image-info.json] (supposed to have copyright)

Description: I haven't read the documentation but here's what I see.
| *path/field* | *eg* | *description* |
| *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 |
| ./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] 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] 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 | (?) |
| ./cas | false | (?) |
| ./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 | (?) |
| ./cas | false | (?) |
| ./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 for Lec:
- are there other formats that we care about?&nbsp;
-* Lec: we only care about image/jpeg, image/tiff, image/jp2 \-\- in the longer future maybe pdf/a, mp3, mp4, 3D formats, TBD as they will have different viewers
- do all webStatement and usageTerms redirect to [http://britishart.yale.edu/collections/using-collections/image-use] http://britishart.yale.edu/collections/using-collections/image-use ?
-* Lec: for now yes, but in the long run this may not be the case. This data comes from Digital Asset Managment, so if our registrar changes it there it will be reflected in this data
- Even the object you said is copyrighted (5054) points to the same page: [http://deliver.odai.yale.edu/info/repository/YCBA/object/5054/type/2?output=json]
-* Lec:&nbsp;
- are there any imageCopyrightNotice and imageCopyrightMarked with true?
-* &nbsp;
- Even the object you said is copyrighted (5054) doesn't have these.
-* &nbsp;
- what are unitAccessOnly and cas, and do we care?
-* Proxy, CAS, login + session ticket. We do care as Linked Data may not always be Open, we can have some LOD and some LD. I can imagine on the long run giving access to all data and those without access with only see LOD. For now you can ignore.&nbsp;

h3. Image Redirects

ODAI has setup two URLs that both redirect to the physical URL:
# Using ODAI GUID:
# (!) As described in [#Deep Zoom Image], the deep zoom format [http://deliver.odai.yale.edu/content/repository/YCBA/object/7/image/0/format/7]
should NOT redirect to [http://deliver.odai.yale.edu/content/id/482f519c-eebf-4596-819c-4c8197c4d3e5/format/1] since this serves the whole image.
Instead, it should redirect to [http://collection.britishart.yale.edu/danprac/iip.html?image=482f519c-eebf-4596-819c-4c8197c4d3e5&credit=%20] [http://scale.ydc2.yale.edu/iiif/482f519c-eebf-4596-819c-4c8197c4d3e5].

Below I use such URLs in examples. If YCBA cannot set such redirects, it should use the GUID-based URLs (1). In any case:
- (i) Use the actual deliver.odai.yale.edu URL for the images, not a "made up" node with identifier pointing to that URL
In summary (format/7 goes to an IIP Server, *not* to the whole JP2000 image)
| *view* | *fm* | *format* | *logical URL* | *redirect* |
| 0 | 1 | sm | http://deliver.odai.yale.edu/content/repository/YCBA/object/7/image/0/format/1 | http://deliver.odai.yale.edu/content/id/482f519c-eebf-4596-819c-4c8197c4d3e5/format/1 |
| 0 | 2 | med | http://deliver.odai.yale.edu/content/repository/YCBA/object/7/image/0/format/2 | http://deliver.odai.yale.edu/content/id/482f519c-eebf-4596-819c-4c8197c4d3e5/format/2 |
| 0 | 3 | large | http://deliver.odai.yale.edu/content/repository/YCBA/object/7/image/0/format/3 | http://deliver.odai.yale.edu/content/id/482f519c-eebf-4596-819c-4c8197c4d3e5/format/3 |
| 0 | 6 | print-lg | http://deliver.odai.yale.edu/content/repository/YCBA/object/7/image/0/format/6 | http://deliver.odai.yale.edu/content/id/482f519c-eebf-4596-819c-4c8197c4d3e5/format/6 |
| 0 | 7 | JPEG2000 | http://deliver.odai.yale.edu/content/repository/YCBA/object/7/image/0/format/7 | http://scale.ydc2.yale.edu/iiif/482f519c-eebf-4596-819c-4c8197c4d3e5 |
| 1 | 1 | sm | http://deliver.odai.yale.edu/content/repository/YCBA/object/7/image/1/format/1 | http://deliver.odai.yale.edu/content/id/279ce6c0-c584-43e4-a5b4-5af2c90b82a0/format/1 |
| 1 | 2 | med | http://deliver.odai.yale.edu/content/repository/YCBA/object/7/image/1/format/2 | http://deliver.odai.yale.edu/content/id/279ce6c0-c584-43e4-a5b4-5af2c90b82a0/format/2 |
| 1 | 3 | large | http://deliver.odai.yale.edu/content/repository/YCBA/object/7/image/1/format/3 | http://deliver.odai.yale.edu/content/id/279ce6c0-c584-43e4-a5b4-5af2c90b82a0/format/3 |
| 1 | 6 | print-lg | http://deliver.odai.yale.edu/content/repository/YCBA/object/7/image/1/format/6 | http://deliver.odai.yale.edu/content/id/279ce6c0-c584-43e4-a5b4-5af2c90b82a0/format/6 |
| 1 | 7 | JPEG2000 | http://deliver.odai.yale.edu/content/repository/YCBA/object/7/image/1/format/7 | http://scale.ydc2.yale.edu/iiif/279ce6c0-c584-43e4-a5b4-5af2c90b82a0 |

h3. Image Sizes
Below I use such URLs in examples. If YCBA cannot set such redirects, we'll use the GUID-based URLs (1).
(i) In any case: use the actual deliver.odai.yale.edu URL for the images, not a "made up" node with identifier pointing to that 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 for [#Deep Zoom Image] annotation since it serves the whole image |
| 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:
- *main*: [http://collection.britishart.yale.edu/danprac/iip.html?image=1b747e8f-7754-482c-b5a2-9e1dc1986f4b]
- *X-Ray*: [http://collection.britishart.yale.edu/danprac/iip.html?image=8621278e-1ebc-4548-8834-0124ee800c41]

RS implements Image Annotation over Deep Zoom images (JPEG2000) served by IIP Server.
Many YCBA objects have Deep Zoom images, sometimes even several per object. Eg Miss Prue [http://collections.britishart.yale.edu/vufind/Record/1669236] has:
- main: [http://collection.britishart.yale.edu/danprac/iip.html?image=1b747e8f-7754-482c-b5a2-9e1dc1986f4b&credit=Sir%20Joshua%20Reynolds,%201723-1792,%20British,%20Mrs.%20Abington%20as%20Miss%20Prue%20in%20&quot;Love%20for%20Love&quot;%20by%20William%20Congreve,%201771,%20Oil%20on%20canvas,%20Yale%20Center%20for%20British%20Art,%20Paul%20Mellon%20Collection]
- X-Ray: [http://collection.britishart.yale.edu/danprac/iip.html?image=8621278e-1ebc-4548-8834-0124ee800c41&credit=Sir%20Joshua%20Reynolds,%201723-1792,%20British,%20Mrs.%20Abington%20as%20Miss%20Prue%20in%20&quot;Love%20for%20Love&quot;%20by%20William%20Congreve,%201771,%20Oil%20on%20canvas,%20Yale%20Center%20for%20British%20Art,%20Paul%20Mellon%20Collection]
This is an IIPMooViewer client using a Djatoka Adore IIIF server
- the server implements this URL-based protocol:
[http://www-sul.stanford.edu/iiif/image-api/]
- the sc:hasRelatedService URL for the first image is:
[http://scale.ydc2.yale.edu/iiif/1b747e8f-7754-482c-b5a2-9e1dc1986f4b]
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]
- 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/]

The Deep Zoom URLs are not recorded directly in the [#Image Metadata] but are easy to compute
- whenever an Image View X has formatid=7 (X/derivatives/7/formatId=7), it has a Deep Zoom image
- form the URL using X/contentId (or X/derivatives/7/contentId) and this template:
{noformat}http://collection.britishart.yale.edu/danprac/iip.html?image=<contentId>&credit=%20{noformat}
eg [http://collection.britishart.yale.edu/danprac/iip.html?image=482f519c-eebf-4596-819c-4c8197c4d3e5&credit=%20]
- Note1: the "credit" parameter shows a credit line. Above we use just a space, but it's better to form one from the painter, year, and YCBA's name
- Note2: if you request non-existing contentId, you get "Error: No response from server [http://scale.ydc2.yale.edu/iiif]".
I think once I got it for an existing contentId, but it seems that was a temporary outage
RS implements Image Annotation over Deep Zoom images using IIP Server.
{status:title=TODO|color=red} Implement IIIF tiles in RS Image Annotation, and multiplexing between IIP and IIIF

(?) TODO Jana: this IIP has extra elements on screen. Will they hamper RS image annotation, and does Lec need to talk to the IIP server admin?
- top left: "Y"
- top right: small view and controls
- bottom right: credit line
[#Image Metadata]
- The URL included in the metadata (X/derivatives/7/url), eg [http://deliver.odai.yale.edu/content/id/1b747e8f-7754-482c-b5a2-9e1dc1986f4b/format/7], is not appropriate since it serves the whole image.
- One should concatenate the server URL [http://scale.ydc2.yale.edu/iiif/] and X/derivatives/7/contentId to make the sc:hasRelatedService URL, which is used as base of the tile URLs

h3. Image Views

Image Views are different photographs of the same painting, using different modes (Flags or Kinds).
Eg the lovely Miss Prue [http://collections.britishart.yale.edu/vufind/Record/1669236] has 8 image views, each with 1..3 comma-separated Flags:
0. cropped to image, recto, unframed (0 is always the Main View)
1. recto, unframed

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 represent this by breaking on space and making a thesaurus:
For now I think it's enough to lump them in one thesaurus, eg:
{noformat}
<http://collection.britishart.yale.edu/id/object/5005>
PX_has_main_representation <http://deliver.odai.yale.edu/content/repository/YCBA/object/5005/image/0/format/2>.
<http://deliver.odai.yale.edu/content/repository/YCBA/object/5005/image/0/format/2>

h3. Image Rights

- (-) This says nothing (has no fields)
<object/7/image/1> P104_is_subject_to [http://collection.britishart.yale.edu/id/page/object/7/image/1/restriction]
-- Vladimir: indeed, BM claims rights (eg images\assets_0.trig):
{noformat}
<http://collection.britishmuseum.org/id/object/MCT3411>
crm:P138i_has_representation <http://www.britishmuseum.org/collectionimages/AN00589/AN00589075_001_l.jpg>.
<http://www.britishmuseum.org/collectionimages/AN00589/AN00589070_001_l.jpg>
crm:P105_right_held_by thesIdentifier:the-british-museum.
{noformat}
-- Vladimir: My example above (6) says the image P104_is_subject_to a Rights object, which allows unrestricted usage. See the scope note to be convinced this is the right class to use: "This class comprises legal *privileges* concerning material and immaterial things". It doesn't say YCBA holds any rights.
-- For (7) it would be nice to compute the actual holder of rights and state P105_right_held_by but that's not easy
-- Emmanuelle: OK, I see that P104_is_subject_to is good even when no image restrictions apply. Then let's use P104_is_subject_to

h3. Image Representation

(-) both of these are wrong, see [image_objects_carriers@crmg]
{noformat}

h3. Image Creation

- (-) this is wrong
{noformat}

h3. Image Derivation

We connect only format/2 directly to the object (P138i) and declare the other formats derivatives thereof (P130i)
{noformat}

h3. Image RDF

Tying it all together, this section defines the RDF mapping for images.
- We assume [#Image Redirects] are set for all image views
{noformat}
# Prefixes
#prefix crm: <http://erlangen-crm.org/current/> . # assumed by default below
@prefix dc: <http://purl.org/dc/elements/1.1/> . # Dublin Core Elements
@prefix dct: <http://purl.org/dc/terms/> . # Dublin Core Terms
@prefix exif: <http://www.w3.org/2003/12/exif/ns#> . # EXIF vocabulary
@prefix bmo: <http://collection.britishmuseum.org/id/ontology/> .

# image/0/format/2 is the main format
<http://deliver.odai.yale.edu/content/repository/YCBA/object/7/image/0/format/2>
a E38_Image;
bmo:PX_image_flag <yale/thes/image/flag/cropped_to_image>, <yale/thes/image/flag/recto>, <yale/thes/image/flag/unframed>;

# image/0/format/1
<http://deliver.odai.yale.edu/content/repository/YCBA/object/7/image/0/format/1>
a E38_Image;
bmo:PX_image_flag <yale/thes/image/flag/cropped_to_image>, <yale/thes/image/flag/recto>, <yale/thes/image/flag/unframed>;
dc:format "image/jpeg" ;
P94i_was_created_by <http://collection.britishart.yale.edu/id/object/7/image/creation>.
# ... image/0/format/3,6,7 are similar and differ only by size and dc:format. format/7 is used for Deep Zoom

# format/7 is used for Deep Zoom
<http://deliver.odai.yale.edu/content/repository/YCBA/object/7/image/0/format/7>
a E38_Image;
bmo:PX_image_flag <yale/thes/image/flag/cropped_to_image>, <yale/thes/image/flag/recto>, <yale/thes/image/flag/unframed>;
P104_is_subject_to <http://britishart.yale.edu/collections/using-collections/image-use> ;
bmo:PX_image_format <yale/thes/image/format/JPEG2000> ;
exif:height 4279 ; #
exif:width 3201 ;
dc:format "image/jp2" ;
# It's on an IIIP server. Next statement suggested by Michael Appleby
dct:conformsTo <http://library.stanford.edu/iiif/image-api/1.1/conformance.html#level1>;
P94i_was_created_by <http://collection.britishart.yale.edu/id/object/7/image/creation>.

# image/1: similar, only Image Flags are different
<http://deliver.odai.yale.edu/content/repository/YCBA/object/7/image/1/format/2>
a E38_Image;
bmo:PX_image_flag <yale/thes/image/flag/recto>, <yale/thes/image/flag/unframed>;

# Shared Creation node
<http://collection.britishart.yale.edu/id/object/7/image/creation>
a E65_Creation;
P14_carried_out_by <thesauri/ULAN/500303557>;

h2. Depiction

Couple issues here:
{noformat}
# image/X: see [#Image RDF]

h2. Local Terms

(TODO: move to Thesauri section)
- (-) don't export a term as "-1"
[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
- Lec: Emmanuelle there are cases where subjects are TGN where conceptID = 0, I will try to ignore. Example ObjectID = 34
- Vlado: in chat Emmanuelle said "-1" represent Yale local terms. Then emit them as such, don't look them up in AAT

h2. Acquisition

- (+) P30_transferred_custody_of is wrong direction
Lec: Replaced with P30i_custody_transferred_through

h2. Object Rights

- PX_has_copyright "Public Domain" is unnecessary since you have it structured as
[http://collection.britishart.yale.edu/id/page/object/7/object-rights].

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

What do I do for the following crm:P14_carried_out_by association codes? Do they become types or labels?
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:

h2. Unknown Artist

Some records say "production performed by Unknown Artist".
- (?) Lec: removed unknown artists, this will need to be communicated with Emmanuelle, she has some reservations about it. In effort to get our data to work with RS I made the change.
- Vladimir's considerations:
- Vladimir: You can express "French" and "Sculptor". Here's how the BM thesauri are modeled:
{noformat}
<http://collection.britishmuseum.org/id/person-institution/207075>
a crm:E21_Person, skos:Concept;
skos:inScheme id:person-institution;

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:] http://research.ng-london.org.uk/wiki/index.php/Category:EN41-Artist_Sub_Group:
The production of a particular painting (E84) was carried out by an Unknown Artist (E21) who was known to be part of the EN41.Artist_Sub_Group of a known/individually defined Master (E21)
-- I have represented this logic in the attached graph. On the model of the NG I have also moved Circle of, Studio of and Workshop of to be Production association codes for E74_Group.

- Vlado: this closely follows [BM Association Mapping v2#Production by Closely Related Group], and it's more faithful modeling than before. But it has implications for Search that need to be discussed with BM.
(?) Need to track the discussion at [BM Association Mapping Problems#Closely Related Group].
- Vlado: not all these codes are the same, and they map to *different CRM constructs*. I would group the NG codes as follows:
-- EN20-Studio of, EN23-Circle of, EN24-Workshop of, EN25-School of: [BM Association Mapping v2#Production by Closely Related 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\! 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\!)
Note: We should qualify production/1 with an EX_Association having type "unlikely/formerly-attributed-to" (this is described well at the page [BM Association Mapping v2]
-# In another case there may be actual evidence of 2 producers (e.g. Rembrandt and someone unknown from his Workshop).

h2. Curatorial Comment

- (-) Yale: PX_curatorial_comment needs date and author added to the data model
- Vlado: this is clearly a case of EX_Association. It's is a subclass of E13_Attribute_Assignment, so see [attribute_assignment@crmg] and [recorder@crmg]:

h2. Inscriptions

(?) I haven't seen any Inscription info in TTL. And in LIDO I see only empty XML tags for the following types but without data:
{code:xml}

h2. Object Type and Genre

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

h2. Current Owner, Keeper

(-) This is probably wrong, it should describe the specific sub-organization (department):
{noformat}

h2. Current Location

You currently use per-object place representations. Such places are not searchable, and
{noformat}
<http://collection.britishart.yale.edu/id/object/5005/location/1> a crm:E53_Place ;

h2. Dimensions

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

h2. Bibliography

Page numbers, eg for [http://collection.britishart.yale.edu/id/bibliography/2775]