Hello Vladimir, I want to mention 3 relevant side dishes for your 2 main courses below:
1. CRM has one notion of preferredness: 0. crm:P48_has_preferred_identifier. That's really interesting considering that CIDOC has a proposal for authoritative URI curation: see http://www.cidoc-crm.org/URIs_and_Linked_Open_Data.html & http://cidoc.meta.se/forum/viewtopic.php?f=44&t=192 I think that *all other preferred properties will derive precisely from this* - because the source of the URI is also the determinant for the curation & documentation context, which should ideally specify clear use cases for preferring some "versions" above others. This chimes with CIDOC's aim to allow a plurality of contexts but a single integration environment where URIs must be fixed and reliable (and usable... but that's another thread). It also makes sense of the (real) problems you raise later: - 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) This is in the application context - not the integration context where CRM has its (deliberately very limited) scope. - users do not (or should not) care about identifiers Again - in the application context, they care about *actionable* identifiers. But again, it's a function of the application environment. Which leads us on to: 2. Contextual identification: see http://www.erpanet.org/events/2004/cork/presentations/040617PaskinPIConcepts.pdf and http://www.dlib.org/dlib/january03/paskin/01paskin.html and http://www.dlib.org/dlib/april06/paskin/04paskin.html 3. At the application level we need some kind of schema level description of the context, rather than an integrating ontology as CRM is and should be. Examples are: www.lido-schema.org http://www.cidoc-crm.org/crm_core/demo/index.htm ...etc... I'm copying in Regine with whom I've had this sort of conversation several times already! Best, Michael -----Original Message----- Message: 1 List-Post: [email protected] Date: Wed, 21 Nov 2012 12:23:32 +0200 From: "Vladimir Alexiev" <[email protected]> Subject: [Crm-sig] ADDITION: property "active in period" To: <[email protected]> Message-ID: <01fc01cdc7d2$421eb260$c65c1720$@[email protected]> Content-Type: text/plain; charset="us-ascii" I propose to add a new property "active in period" with range E4 Period. ------------------------------ Message: 2 List-Post: [email protected] Date: Tue, 20 Nov 2012 12:57:45 +0200 From: "Vladimir Alexiev" <[email protected]> Subject: [Crm-sig] Preferred Identifier vs Appellation vs Image 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
