global Title mapping

[VladimirAlexiev]

Consider eg LOD CBMAA Titles.csv that includes eg this record:

ObjectID=     197
TitleID=      6,716  (someone printed the ID with a decimal separator, silly)
Title=        From "Album Unique" formerly in the collection of the Duke of Portland
TitleTypeID=  4
TitleType=    Group Title
DisplayOrder= 2
DataDate=     12/23/2015

The global Title mapping http://review.americanartcollaborative.org/entity/E22_Man-Made_Object#field_1-search_0 has the following problems:

• doesn't specify the URLs, which has allowed the mapping implementers to botch it like this: https://github.com/american-art/cbm/issues/58 items 1 and 2 (TWO wrong URLs in one mapping!)
• The title type (eg http://data.americanartcollaborative.org/page/cbm/object/197/title_type) mixes SKOS (skos:prefLabel) and CRM (crm:E55_Type) in an undisciplined way
• There's no relation of title type to AAT. Whenever you need a concept like Group Title, write to Patricia and she'll add it. (AFAI remember, CCO has such a concept)
• DisplayOrder is not modeled but often it is important (@azaroth42: back to the discussion whether using rdf:List is appropriate for this. crm:P102_has_title cannot point to a rdf:List)
• A more subtle problem: Group Title reflects a collection of objects so it should be modeled as crm:E78_Collection

[workergnome]

1. We can't use crm:E78_Collection, because there's not an explicit collecting plan.
2. Even if there were an AAT term, the museum has not reconciled their internal thesaurus to the AAT yet, so it's valid to use local thesauri.
3. I don't see any issues using both SKOS and CRM together.
4. It may have been the wrong decision, but I didn't think it was my responsibility (as the developer of the Browse app) to specify the URL patterns for the mappings. I can work with whatever, as long as they're conceptually valid. I agree that the mappings here are not valid, and will need to be fixed, but I didn't want to impose my preferences on how they should be assigned on ISI.
5. I'm not going to touch the displayOrder issue. That conversation is out of my league.

[azaroth42]

I agree that CRM is broken when it comes to ordering. That's a tradeoff of choosing CRM. displayOrder as a global property is also broken, it needs to be an overlay similar to ore:Proxy or schema:ListItem.

The issues with the definition of CRM's Collection are well understood and unsolvable.

Propose close.

[VladimirAlexiev]

@azaroth42 Should I post any issues at all then?

[azaroth42]

As discussed, our target model is fixed for the current project. So any model changes are not in the scope of work for 2017 for AAC. Feel free to post issues, but expect not to get much traction on solutions.

[VladimirAlexiev]

All issues that I post in this project are for a future version. But you take them all as "propose to close" (not relevant? wrong? insurmountable?) So I'm wondering if I should bother to post any.

If we continue a specific discussion in this issue: CRM is not broken when it comes to ordering. CRM merely lacks ordering. The source data has a field DisplayOrder, which is often important, so it should be mapped. There are many ways to implement ordering:

• CO: http://purl.org/co/, which is used by SPAR (eg http://www.sparontologies.net/examples#fabio_2)
• OLO: http://smiy.sourceforge.net/olo/spec/orderedlistontology.html
• rdf:List, which IMHO is not the best way for the reasons explained before (most importantly, rdf:next*/rdf:first is not guaranteed to return them in a specific order)
• a custom prop right in the Title. Because Titles are not shared between objects, that's an adequate and the simplest solution.