Issue 220: Notion of preferredness

ID: 
220
Starting Date: 
2012-11-20
Working Group: 
3
Status: 
Done
Closing Date: 
2012-11-21
Background: 

Posted by vladimir.alexiev on 20/11/2012 

CRM has one notion of preferredness: 
0. crm:P48_has_preferred_identifier. 

However, in any system that displays search results, it's important to know two other preferred attributes of an object: 
1. Preferred image: to be shown as thumbnail in a result list or lightbox 
2. Preferred label (name/title/appellation): to be shown as short textual representation of the object 

In ResearchSpace we've tackled this in some way, even though imperfect: 
1. For BM data: subproperty bmo:PX_has_main_represesentation of crm:P138i_ has_representation 
For RKD data: subclass rso:E38_Main_Image of crm:E38_Image 
2. Following LOD best practice, we try to make rdfs:label for every object. 
This is rife with its own problems, e.g. because thesaurus terms have a different one (skos:prefLabel). 

I wonder why CRM standardizes 0 but not 1 & 2. 
It seems to me the notion of preferred identifier is least useful of the three because: 

- when you integrate data from various systems (CRM's forte), each will come with it's own notion of primary key, so there won't be agreement on "preferred identifier". 
In contrast, there may well be agreement on preferred image (e.g. full frontal) and appellation (e.g. official title) 
- users do not (or should not) care about identifiers 
 



Let's say we have these attributes and want to add that they are preferred: 
P1_is_identified_by 
P102_has_title 
P138i_has_representation 

There are various ways: 

A. With a subclass (like rso:E38_Main_Image above) 

B. With a subproperty (like crm:P48_has_preferred_identifier or bmo:PX_has_main_represesentation above) 

C. With a property-property: P102.1 has type, P138.1 mode of representation (curiously, there's no P1.1) 

D. With a type in the attribute. E.g.: 
P2_has_type ; P3_has_note "2926". 
P2_has_type ; P3_has_note "De badende Suzanna". 
P2_has_type ; P2_has_type 

E. With a type in the Attribute Assignment, as per P48's scope note: 
"The fact that an identifier is a preferred one for an organisation can be better expressed in a context independent form by assigning a suitable E55 Type to the respective instance of E15 Identifier Assignment" 

I tend towards D, with a property such as "P200 is preferred" on E1 

 


Posted by vladimir.alexiev 
Sent: Tuesday, November 20, 2012 12:58 PM 
Subject: Preferred Identifier vs Appellation vs Image ... a property such as "P200 is preferred" on E1 

A scope note could be something like this: 
"Whether this entity should be preferred amongst all other entities falling in a given set (e.g. the Identifiers, Appellations or Image representations of some Man-Made Object). Such naive global notion of preference may be useful in scenarios where an object needs to be represented by one of its related Appellations and/or Images (e.g. search result lists). You can use Attribute Assignment in order to express who and when expressed this preference."

The above is motivated by the need to use a particular image of an object as its thumbnail. 

Joshan added the following: 
the sequence (order) of images is also important, particularly for objects with lots of images 

This could be added as a property P201_sort_order from E1 to Number with scope note "Sort ordering of this entity amongst all other entities falling in a given set" ... (then similar to the above) 
 



RDF naturally represents multi-valuedness: if you have a statement you can always add e.g. 

P138i_has_representation ,

But RDF doesn't naturally represent order amongst these values. E.g. if you say 
P138X_has_representations ( ). 
that means an rdf:List 
[ rdf:first (; rdf:rest [ rdf:first (; rdf:rest rdf:nil ] ] 
http://www.w3.org/TeamSubmission/turtle/#sec-collections 
and totally changes the data representation. 

(Luckily, OWLIM returns results in the same order as inserted, but that's not guaratneed).
,p,on>
,p,o1>

 

Current Proposal: 

General notion of preferredness is not present in current documentation practice. It can adequately be addressed by using solution E. as part of an implementation. 
CRM-SIG meeting. Stockholm 7/6/2013