On "Node-ifying" Relations in a Neo4j Graph Database of the CIDOC-CRM

I am very fortunate to be developing a Personal Learning Network with some amazingly brilliant people helping me to fast-track my learning and use of the ICOM CIDOC-CRM – that is, the ISO standard Conceptual Reference Model (i.e. a metamodel) for museum cultural artifact description, preservation and associated collection management developed by the International Council of Museums (ICOM).

As the learner of a PLN network, you look for opportunities to "give" as well as "take" as we are too often on the taking side of things. As in our taking of valuable time and energy from our PLN mentors. So looking for such an opportunity to give something back, I mentioned to Dominic Oldman -- of the British Museum, its www.ResearchSpace.org project, and member of the CIDOC-CRM SIG -- that I would like to make a community contribution of a more intuitive and easier-to-navigate exploratory viewer for the CIDOC-CRM Definition reference. He said that sounded like a good idea. So this post is related to that quest.

Some quick background... I am designing the FactMiners LAM-based (Libraries, Archives, and Museums) social-game platform based on an "embedded metamodel subgraph" design pattern. To make the output of our FactMiners gameplay useful, not just for casual visitor engagement, but for scholarly and scientific research, we have adopted the CIDOC-CRM as our primary Reference Model in the META partition (subgraph) of the FactMiners Fact Cloud. So while we are building a social-game platform on the one hand, it will also be a credible CIDOC-CRM compatible platform that can be easily and modularly extended into a full-featured digital collection management system on the other.

It is our hope that the FactMiners social game platform will find broad use in grassroots digital Citizen History projects due to its "seriously fun" gameplay and associated player community. But with our underlying CIDOC-CRM compatible "gameflow", we will produce digital cultural heritage collections that can be both immediately published to evolving #LODLAM (Linked Open Data in Libraries, Archives, and Museums) standards, as well as easily transferred to more sustainable long-term preservation within fully-curated institutional collections.

"Node-ifying" a Graph Relationship -- DIY 2-D Hypergraph!?

One aspect of my metamodel subgraph design pattern has to do with a graph transformation that can be viewed as "node-ifying" a relationship. That is, in order to more completely model a relationship in a target graph, we explicitly model the target relationship as a node in our metamodel. I think of this transformation as an elementary "2-dimensional hypergraph" in that the "node-ified" relationship and its domain and range relationships are a subgraph decomposition of the target graph's relationship. The cartoon graphic accompanying this post more easily demonstrates this mapping/transformation.

cidoc-crm-graph-representation-challenges.png

If you look at the official 'Definition of the CIDOC Conceptual Reference Model' (PDF), you see the two primary content divisions of the Class and Property Declarations. The basic building block model elements are described as class/nodes and property/relationships. When graphical diagrams of the CIDOC-CRM are provided, this "class as node" and "property as relationship" concept is clear.

But a closer reading of the Property Declarations shows that the "devil is in the detail." That is, in order to do a graph model of the Property Declarations, we need relations to have relations. The most obvious examples of this being the superproperty and subproperty relationships, and the "Pxx.1 has type" properties. At first this realization hit me with a, "Hmmm, this could be trickier than I thought..." Moment.

Things get complicated very quickly when you cross over into "hyper zone" with graph thinking. And more importantly, the incredibly powerful and widely available Open Source graph databases like our choice, Neo4j, do not support relationships having relationships. But then I clicked on the idea that using the "node-ifying" relationship pattern, like what I'm doing in the FactMiners META subgraph, could work well in building an exploratory viewer for the CIDOC-CRM Definition.

cidocCRM_graphrep_hotspots.png

To bring the CIDOC-CRM Definition "to life" in an exploratory viewer, we'll need to provide "shortcut" (i.e. collapsed) visualizations of the model that make the resulting interactive graphical diagrams less cluttered and more intuitively meaningful.

The most awesome platform I can imagine on which to build this exploratory viewer is a Neo4j-based Struct-powered web and mobile app with client-enhanced views based on the equally brilliant KeyLines graph visualization product. As a next step in my quest to provide the CIDOC-CRM community with a new model viewing resource, I will be asking Cambridge Intelligence's U.S. developer rep, Corey Lanum, to check out this post. Can the powerful visualization features of KeyLines be harnessed to provide a "collapsed/expanded" visualization for my CIDOC-CRM Explorer that defaults to the "relationship as relationship" view with a double-click event toggling in and out of the expanded "node-ified" full-path view?

I am anticipating that KeyLines can do what I need. This seems like just the kind of view transformation mapping that could/should be pushed to a dynamic visualization level decision rather than be made at the database design level. I will update this post as this exploration unfolds...


For more, see my initial explorations in this GraphGist: The CIDOC-CRM in a Neo4j Graph Database.