Hi Philip! I very much like Stephen's suggestion of modelling generic relationships by reifying subsets of the museum's database records as a set of E73 Information Objects each of which *P67 refers to* a set of "generically related" objects. The nice thing about an "Information Object" is that the semantics it carries are not required to be expressed in terms of the CIDOC-CRM, so it doesn't matter that the exact semantics aren't known. This technique seems to me like it could be a useful very generally for representing information from legacy systems with under-specified semantics.
I was confronted with the same issue when I was experimenting with building a CIDOC-CRM interpretation of the data exposed by Museum Victoria's Collections API. Actually, I wish I'd thought of Stephen's approach, now, rather than the approach I took, which wrote up on my blog: < http://conaltuohy.com/blog/bridging-conceptual-gap-api-cidoc-crm/> Of particular relevance to your question is the section about how to model these "generic relations" between collection items: < http://conaltuohy.com/blog/bridging-conceptual-gap-api-cidoc-crm/#relationships>. The problem is that MV's underlying database records did not document any detailed semantics for this relationship, and that a number of different types of relationships might have been represented using the same data structure. If you are aiming to model the relationship as something general enough to subsume all the instances of the relationship, the owl:topObjectProperty would certainly work for this purpose, but you might perhaps find something semantically stronger. Empirical investigation might allow you to use one of the CIDOC-CRM's properties (though it might show that the general relationships are actually too heterogeneous for that). In the case of my experiment, my reading of MV's data led me to believe that the actual relationships could legitimately be encoded as relationships of similarity, and represented with P130_shows_features_of (in the symmetrical, non-directed sense of that relationship), though this was controversial, as you can see by the comments on the post: < http://conaltuohy.com/blog/bridging-conceptual-gap-api-cidoc-crm/#comments> The other approach would be to try to guess at a more particular meaning for each of these "general relationships", using clues from other available data. You might find that the "general relationships" between photographs and other items was one of depiction, for instance, and be able to automate that inference in your mapping. But that's an empirical question, and potentially a lot of work. Regards Conal On 15 September 2016 at 20:16, Carlisle, Philip < [email protected]> wrote: > Hi all, > > > > The Arches project moves on a pace and is in the process of modifying the > graphs for version 4. > > > > In the original graphs we used a British Museum extension property > (PXX_is_related_to) as a work around to allow us to represent the general > association relationship we had in legacy datasets. eg. this telephone > kiosk has a general association with this telephone exchange. > > > > We now want to continue to be able to model a general association but the > only property available P69 has association with (is associated with) is > restricted in its domain and range to E29 Design or Procedure. > > > > How do we model the ‘If you’re interested in that you might be interested > in this’ nature of the general association between two physical man made > things? > > > > All thoughts appreciated. > > > > Phil > > > > *Phil Carlisle* > > Knowledge Organization Specialist > > Listing Group, Historic England > > Direct Dial: +44 (0)1793 414824 > > > > http://thesaurus.historicengland.org.uk/ > > http://www.heritagedata.org/blog/ > > > > Listing Information Services fosters an environment where colleagues are > valued for their skills and knowledge, and where communication, customer > focus and working in partnership are at the heart of everything we do. > > > > > > _______________________________________________ > Crm-sig mailing list > [email protected] > http://lists.ics.forth.gr/mailman/listinfo/crm-sig > > -- Conal Tuohy http://conaltuohy.com/ @conal_tuohy +61-466-324297
