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

Changes (48)

View Page History

h2. General
- (-) {status:low prio|color=gray} Pubby prefixes are not setup: shows "?:..."
Lec: does same for BM, will try to fix
- (+) STRONGLY Suggest to have 1 URI per object, not 3 sameAs URIs
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
- (-) 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.
- (-) Please use bmo:EX_Association and not ycba:EX_Association: don't define your own class for 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

h2. Whole Getty or Parts
{status: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]
- This way you repeat data about the same term in many objects
- If you start emitting objects in separate graphs like BM does (to be able to easily replace/delete), the term data will be duplicated in each of these object graphs
As you can see already happens about YCBA itself:
{noformat}
<http://vocab.getty.edu/resource/ulan/subject/500303557> a crm:E74_Group , skos:Concept ;
skos:prefLabel "Yale Center for British Art" ;
skos:inScheme <http://collection.britishart.yale.edu/id/thesauri/institution> ;
a crm:E74_Group , skos:Concept ;
skos:prefLabel "Yale Center for British Art" ;
skos:inScheme <http://collection.britishart.yale.edu/id/thesauri/institution> .
{noformat}
- In several cases these in-object ad-hoc terms don't satisfy Thesaurus Requirements (see next section)

(-)(-) My strong recommendation is to export the complete Getty thesauri
- we shouldn't wait for Getty to do an official mapping, since it'll take a few months for TGN and ULAN, and it won't satisfy the requirement to publish as CRM (see next section)
- I can do this mapping. I'll also be involved in the Getty's mapping, so that's a good synergy
- use a separate thesaurus export config, like BM does

I think this is the biggest outstanding Yale task.
Lec: I export terms within objects because they are present in the LIDO XML.
But to export the complete tehsauri, I would need to get someone to export from RDBMS, and we cannot do this right now

Decision:
- For the time being we'll stay without Broader terms
- Dominic and Vlado to try to expedite the Getty export by Getty

h2. Thesaurus Requirements
You must comply with [BMX Issues#Thesaurus requirements]

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)
-- - This applies to both Getty and YCBA local thesauri.
-- (!) TODO RS: - {status:future:color=blue} extend RS to handle AAT, which is AAT as one ConceptScheme that includes a number of facets (hierarchies) for object type, material, technique, etc
- For now: Yale will export AAT terms in different concept schemes, eg:
{noformat}
aat:123456 skos:inScheme aat_object: . # painting
aat:678901 skos:inScheme aat_material: . # canvas
aat:234567 skos:inScheme aat_technique: . # oil
aat:890123 skos:inScheme aat_subject: . # horse
{noformat}
- TODO Vlado: use actual AAT identifiers above, and use the AAT Facets (top-levels) as concept schemes

Emmanuelle: It would be helpful to briefly go over the definitions for searchable and tagable.

h2. Agents
- (-) here crm:E55_Type is wrong: (+) 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 says one prefLabel (per language). If you don't have a flag in TMS, call the first one prefLabel and the rest altLabel
Group: P95i_was_formed_by, E66_Formation

Lec: we have more variety in Person dates.
- (-) Emmanuelle: to provide some more examples

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:

h2. Titles
- (-) Why do you need these duplicate types?
{noformat}crm:P2_has_type <thesaurus/title/Alternate-title> , <thesaurus/title/alternate> .{noformat}
- (?) I'm not sure what "Repository title" is. But if it means Preferred, then this is also unnecessary duplication:
{noformat} crm:P2_has_type <thesaurus/title/Repository-title> , <thesaurus/title/preferred> .{noformat}
Emmanuelle to clarify.
Can an object have different Repository title and Preferred title?
- (-) these two titles are duplicated. Keep just one of them: I suggest <title/1> for uniformity with the alternate title(s)
{noformat}
<object/19850/title/1> a crm:E35_Title ;
rdfs:label "Malvolio Dancing" ;
crm:P2_has_type <thesaurus/title/Repository-title> , <thesaurus/title/preferred> .
rdfs:label "Malvolio Dancing" ;
crm:P2_has_type <thesaurus/title/Repository-title> , <thesaurus/title/preferred> .
<object/19850/title/primary> a crm:E35_Title ;
rdfs:label "Malvolio Dancing" ;
crm:P2_has_type <thesaurus/title/Repository-title> , <thesaurus/title/preferred> .
rdfs:label "Malvolio Dancing" ;
crm:P2_has_type <thesaurus/title/Repository-title> , <thesaurus/title/preferred> .
{noformat}
- (?) (optional) Indicate the title language:
{noformat}
<object/19850/title/1> a crm:E35_Title ;
rdfs:label "Malvolio Dancing"@en ;
P72_has_language <thesaurus/language/english>.
{noformat}

h2. Acquisition
- don't you know who gave up the object? Or I just hit an object that doesn't have this data?
- (+) The YCBA director does not want to publish which person gave up the object.
Maybe if the person has passed, that can be exported. Emmanuelle to clarify.
{noformat}
<object/19850/acquisition> a crm:E10_Transfer_of_Custody , crm:E8_Acquisition ;
crm:P22_transferred_title_to <thesauri/ULAN/500303557> ;
crm:P29_custody_received_by <thesauri/ULAN/500303557> ;
crm:P22_transferred_title_to <thesauri/ULAN/500303557> ;
crm:P29_custody_received_by <thesauri/ULAN/500303557> ;
rdfs:label rdfs:label "Yale Center for British Art, Paul Mellon Collection" .
{noformat}
- (-) format the label as "Transferred to ..." (now it reads as an Agent, not as a Transfer)
- you state a shorter title about the agent in ULAN. Pick shorter or longer and use it consistently:
- (-) 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 ; skos:prefLabel "Yale Center for British Art" . {noformat}
- (?) 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-agents (or sub-colletions) under it: Paul Mellon Collection, Paul Mellon Fund, Gift of Mr. and Mrs. J. Richardson Dilworth, B.A. 1938.
If it's important to preserve this information in RDF, you could create sub-agents under YCBA, eg like this:
{noformat}
<thesauri/ULAN/500303557> a crm:E74_Group , skos:Concept ;
skos:prefLabel "Yale Center for British Art" ;
<person-institution/ycba_mellon_collection> a E74_Group, skos:Concept;
skos:inScheme <person-institution/>; rdfs:label "Yale Center for British Art, Paul Mellon Collection" ;
skos:broader ulan:500303557; P107i_is_current_or_former_member_of ulan:500303557 .
<person-institution/ycba_dilworth_gift> a E74_Group, skos:Concept;
skos:inScheme <person-institution/>; rdfs:label "Yale Center for British Art, Gift of Mr. and Mrs. J. Richardson Dilworth, B.A. 1938" ;
skos:broader ulan:500303557; P107i_is_current_or_former_member_of ulan:500303557 .
{noformat}

h2. Images
- This (-) this is wrong, see [image_objects_carriers@crmg]
{noformat}<object/7> P62_depicts <object/7/image/1>{noformat}
TODO Vlado: write the correct one
The correct one is:
{noformat}<object/7> P65_shows_visual_item <object/7/image/1>{noformat}
Explanation: an E24_Physical_Man-Made_Thing P128_carries an E73_Information_Object.
In the particular case of E38_Image, we say E24_Physical_Man-Made_Thing P65_shows_visual_item E38_Image
- (-) this is wrong
{noformat}
<object/7/image/1> P108i_was_produced_by <object/7/image/1/creation>. # images are conceptual, so use P94i_was_created_by
BTW: if you have just 1 code, it would be nice to optimize and not create sub-events, but BM doesn't do that


h32. 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.
-- CONS: The sem web way of expressing that some info is missing is simply NOT to say anything.
-- PRO: if you want to search in RS for "paintings with Unknown creator", you can do it when mapped to an Unknown person or Unknown group. But you cannot currently search for "paintings that don't have creator info"
- Ken: Interesting conundrum about "Unknown" but it seems to be exactly as we know the world in traditional data. If one searches simply for Unknown, one does get everything Unknown, and we realize the works are not all by the same maker and that isn't a problem because we understand that Unknown is a class not an individual. Such a search however is usually combined with limiting qualifiers like "Unknown French 18th-century sculptor." Being unable to search in that fashion seems to me the much more limited option.
- Dominic: I am not sure that a person URI should refer to a generic 'unknown' which would be the same unknown person. Generally, if something is unknown it shouldn't have a triple. The absence of a triple means that it is not known. Producing triples that state a null doesn't seem useful. Is there a particular reason for specifically stating that an artist is unknown? A query for an object created in the 18th century, in the french style and that was produced by the technique of sculpting would return the result in the example. Further, if the person was unknown then you couldn't assume that s/he was French. In other words if there is a way to query to get the result required without a null then this seems preferable.
- Emmanuelle: I agree with Ken. 'Unknown creator' for an art historian carries meaningful information. It is not synonym with a null value (of course since all works of art have creators). Rather it means that the attribution research has not come up with conclusive information for now, and that situation can last for many years even centuries.
- Ken: Such a search however is usually combined with limiting qualifiers like "Unknown French 18th-century sculptor." Being unable to search in that fashion seems to me the much more limited option.
- Vladimir: You can express "French" and "Sculptor". Here's how the BM thesauri are modeled:
{noformat}
AJ: Circle/School of: [BM Association Mapping v2#Production by Closely Related Group]
S: School of/style of [BM Association Mapping v2#Influenced By]
- Ken: Interesting conundrum about "Unknown" but it seems to be exactly as we know the world in traditional data. If one searches simply for Unknown, one does get everything Unknown, and we realize the works are not all by the same maker and that isn't a problem because we understand that Unknown is a class not an individual.
-- 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:
{noformat}
<object/7/production/1> crm:P14_carried_out_by <id/person-institution/1180> . # Production by :: Formerly attributed to Benjamin Williams Leader
<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).
- Vlado: The simplest solution could be to just mark with a flag "there's significant unknown info about the producer".

h2. Curatorial Comment
I haven't seen any Inscription info in TTL. And in LIDO I see only empty XML tags for teh following types but without data:
{code:xml}
<lido:inscriptions lido:type="Inscription">
<lido:inscriptions lido:type="Marks">
<lido:inscriptions lido:type="Lettering">
<lido:inscriptions lido:type="Signed and Dated">
<lido:inscriptions lido:type="Inscription">
<lido:inscriptions lido:type="Marks">
<lido:inscriptions lido:type="Lettering">
<lido:inscriptions lido:type="Signed and Dated">
{code}
Are there any objects with inscriptions for me to check?

h2. Object Type and Genre
(-) Object Type and Genre (lido:objectWorkType) are missing, eg
{code:xml}
<lido:objectWorkType>
<lido:conceptID lido:source="AAT" lido:type="Object name">300033618
<lido:term>painting
<lido:objectWorkType>
<lido:conceptID lido:source="AAT" lido:type="Genre">300015636
<lido:term>landscape
<lido:objectWorkType>
<lido:conceptID lido:source="YCBA" lido:type="Genre">7
<lido:term>architectural subject
{code}
- There is a term for the 1st but it's not connected to the object.
{noformat}<http://collection.britishart.yale.edu/id/thesauri/AAT/300033618>{noformat}
- You try to make a term for the 3rd but seems look it up in the wrong thesaurus (it's local not AAT):
{noformat}
<http://collection.britishart.yale.edu/id/thesauri/AAT/-1> a crm:E55_Type , skos:Concept ;
skos:inScheme <http://collection.britishart.yale.edu/id/thesauri/subject> ;
skos:prefLabel "architectural subject" .
{noformat}

I'd represent the first 2 as "type" and the last one as "subject":
{noformat}
<http://collection.britishart.yale.edu/id/object/7>
P2_has_type <http://vocab.getty.edu/aat/300033618>, # painting
<http://vocab.getty.edu/aat/300015636>; # landscape
P62_depicts <http://collection.britishart.yale.edu/id/thesauri/subject/7>. # architectural subject
{noformat}

Note: BM has defined some 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 Yale.

h2. Current Owner, Keeper
(-) This is probably wrong, it should describe the specific sub-organization (department):
{noformat}
crm:P50_has_current_keeper <http://collection.britishart.yale.edu/id/thesauri/department> ;
{noformat}
If you don't have departments in YCBA, just don't say anything about departments.

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 ;
rdfs:label "Bay25" . # UnitType
<http://collection.britishart.yale.edu/id/object/5005/location/2> a crm:E53_Place ;
rdfs:label "401" . # SubSite
<http://collection.britishart.yale.edu/id/object/5005/location/3> a crm:E53_Place ;
rdfs:label "Yale Center for British Art" . # Site
<http://collection.britishart.yale.edu/id/object/5005/location/4> a crm:E53_Place ;
rdfs:label "New Haven" . # Geo location
{noformat}

Recommendations:
- (?) it probably doesn't make sense to put location/1 and location/2 in a thesaurus, so they are correctly per-object. But add something to the label to explain what they mean. If there's a hierarchy between them and the coding won't get too complicated, something like this could be best:
{noformat}
rdfs:label "Storage unit: Bay25, shelf: 401"
{noformat}
- (-) location/3: YCBA is an organization. Here you mean "the place of that org", which is a known conundrum. Since you already say "YCBA is current owner/keeper", just skip
- (-) location/4: A city is a well-known place, so just use the respective TGN URI

h2. Dimensions
You state object dimensions (including their properties):
{noformat}
crm:P43_has_dimension <http://collection.britishart.yale.edu/id/object/7/height> ;
crm:P43_has_dimension <http://collection.britishart.yale.edu/id/object/7/width> ;
{noformat}

(-) But you omit lido:extentMeasurements, i.e. don't state what was measured:
{code:xml}
<lido:objectMeasurementsSet>
<lido:displayObjectMeasurements>12 1/16 x 16 inches (30.6 x 40.6 cm)
<lido:objectMeasurements>
<lido:extentMeasurements>Support (PTG)
{code}
(?) If you have data with lido:qualifierMeasurements, we should also consider it

You can add it like this:
{noformat}
<http://collection.britishart.yale.edu/id/object/7>
P39i_was_measured_by <http://collection.britishart.yale.edu/id/object/7/measurement>.
<http://collection.britishart.yale.edu/id/object/7/measurement> a E16_Measurement ;
P40_observed_dimension <http://collection.britishart.yale.edu/id/object/7/height> ,
<http://collection.britishart.yale.edu/id/object/7/width> ;
rdfs:label "12 1/16 x 16 inches (30.6 x 40.6 cm). Extent: Support (PTG)" .
{noformat}

If "Support (PTG)" is a controlled value, you better make a thesaurus for it and we'll figure how to attach it with P2_has_type.

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