FactMiners.org - Metamodeling

#cidocCRMdev #FlyOnWall Comments Contributed at Schema.org

Jim Salmons — Tue, 12 May 2015 18:15:31 +0000

Context: This is the opening comment I made to a conversation at the GitHub repository for Schema.org where folks are considering a proposal or recommendation to "Add Exhibition as a subtype of Event".

My intent in contributing to this on-going conversation was to be a kind of #FlyOnWall reminder that the #cidocCRM -- the ISO standard Conceptual Reference Model for Museums and other cultural heritage organizations -- can be used as a process-oriented metamodel and not just as a descriptive ontology. This following opening statement can be found here. BTW, this comment can be read as a kind of "There's a pony in there somewhere..." piece to further reinforce the thesis of my "Witmore's Text..." Medium.com article.

Re @BarryNorton and @MiaLondon et al -- Whatever you do, Dan, PLEASE do it so as to be a #cidocCRM-compatible form.

Ontologists tend toward descriptive use of the #cidocCRM as a metaDATA standard when it is intended to also be a metaMODEL supporting its use to prescribe elementary building blocks (model elements, like parts in a LEGO blocks set) of software architectures. Until there is wider recognition of the SIGNIFICANT leverage that metamodel-driven software design can do for the Digital Humanities, the #cidocCRM will be as woefully under-utilized as it is currently under-appreciated. (Yes, as much great work is being done with the #cidocCRM, there is SO MUCH as-yet untapped potential in leveraging its metamodel nature.)

Why do I believe this? I was a lead in a Smalltalk-based skunkworks in IBM's Object Technology Practice doing "executable business model" frameworks in the 1990s behind closed doors of corporate consulting. Our work was inspired by David Gelernter's "Mirror Worlds" book, and was based on "self-descriptive" Smalltalk images that were compliant to an actor/role metamodel that objectified Process (an OOP heresy at the time).

Following my horrific cancer battle and a chance to stick my finger in the eye of the Reaper and come back for some Bonus Rounds, I find myself as a Wolf Child in the Wonderland of Digital Humanities' "Golden Moment."

When we were trying to do EBMs (executable business models) at IBM, we trolled the various IBM Global Services consulting practices for viable IRMs -- each practice was required to create an Industry Reference Model, AKA a metamodel. These IRMs ran the gamut from worthless tripe to "Wow!? Pretty good!"

I most enjoyed "pair programming" with my first ontologist, we called him "Doug the Librarian" because he "just modeled" and didn't code. Basically, what we were looking for in partners to do metamodel-driven software development were three things:

Subject Matter Experts (especially if they were verbal, thinkers, and open to being 'pushed' to clarity)
Explicit Models -- Black box expertise (wetware only) can't be executable without first being rendered in some explicit form of communication (usually words and images)
Source 'Instances' of these Explicit Models -- The best way to surface hidden assumptions and contradictions is to look at the delta of models that purport to be instances of the same metamodel

THE DIGITAL HUMANITIES DOMAIN HAS EVERYTHING NEEDED TO DO METAMODEL-DRIVEN SOFTWARE DESIGN AND DEVELOPMENT IN THE EXTREME! :D

And the #cidocCRM is the BEST opportunity I've seen to date to move in this direction.

Along these lines, I am working on #cidocCRM microservice workflows based on a 'self-descriptive' metamodel subgraph design pattern for LAM-based social games (front-end clients) and #cidocCRM-compliant collections management and scholarly editing back-end.

(BTW, a first step in this regard is to more rigorously express the #cidocCRM in pure-graph form to support vendor- and tech-neutral self-descriptive datastores.)

If anybody is interested in these ideas, please see: http://goo.gl/dpbhPs and http://goo.gl/gS2FJk, etc. at @FactMiners (www.FactMiners.org). This recent Medium.com article is the closest thing to a 'manifesto' on my applied research agenda: http://goo.gl/3Vb0lO.

In closing, I am an unaffiliated independent Citizen Scientist/Historian working from an Outsider POV. Inquiries to clarify ideas as well as explorations of opportunities to collaborate are most welcome @Jim_Salmons, @FactMiners, and @SoftalkApple

FactMiners' Fact Cloud and Witmore's Text as Massively Addressable Object

Jim Salmons — Thu, 09 Apr 2015 16:53:56 +0000

I've just published a long-read, Deep Weedsy piece on Medium.com entitled: "FactMiners' Fact Cloud and Witmore's Text as Massively Addressable Object". I welcome your reading and especially comments and questions.

My purpose in writing this article is two-fold:

As a backgrounder/profile -- a 'manifesto' of sorts -- that I hope Robert Miller of the Internet Archive will have a chance to read before we meet next week at #DPLAfest.

As part of my second post-cancer Bonus Round, my pipedream is to secure the interest and find external funding for a research fellowship to pursue our FactMiners and Softalk Apple Project applied research agenda from a position inside, and with collaborative support, of the Internet Archive to, in effect, join us in exploring the deeper levels of "massive addressability" of the Archive's digital collections, and
As a pubic letter of self-introduction to Michael Witmore, Jonathan Hope and the Computational Literary Linguistics community to explore "Rainman/Sherlock" collaborations as described in this newly published article and its related, earlier piece here.

I invite you to read the full article on your phone or tablet in the Medium app, or on-line in your browser.

Congratulations CIDOC-CRM SIG and the Year Ahead for #cidocCRM Development

Jim Salmons — Tue, 03 Feb 2015 20:08:57 +0000

FactMiners joins the Library, Archive, and Museum (LAM) tech community in congratulating the members of the CIDOC-CRM Special Interest Group for its kick-off to 2015 with release of Version 6.0 of the International Council of Museums (ICOM) Conceptual Reference Model. In addition to the major point update to the model's Reference Document, the CIDOC-CRM SIG also announced a collaboration with the UK-based Collections Trust to create a CIDOC-CRM extension for the Trust's widely-used and highly-regarded SPECTRUM standard for museums' collections management systems.

The CIDOC-CRM (tweeted/hashtagged here and elsewhere as #cidocCRM) serves as a metamodel providing definitions and a formal structure for describing the implicit and explicit concepts and relationships used in cultural heritage documentation. FactMiners is committed to #cidocCRM-driven design for our Open Source social game and exploratory personal and professional "serious fun" research platform.

"Early adopter use cases in the museum community are understandably focused on the descriptive, or ontological, aspects of the CIDOC-CRM. Designing and developing new software systems based on a rigorous metamodel is not the first thing you do with such a resource." said Jim Salmons, tech lead, researcher, and founder of FactMiners and The Softalk Apple Project, "We are very encouraged by publication of the new edition of the Reference Document together with the SPECTRUM announcement. Given the mission and community of The Collections Trust, this is very good news for any museum techies and researchers interested in #cidocCRM-based development projects."

"For our part," Salmons continued, "FactMiners is announcing the launch of our 'Year of the #cidocCRM Full-Graph Deep Dive'. We're asking Kindred Spirits interested in #cidocCRM-driven software design and development to tweet and tag their posts and communications with #cidocCRMdev and #cidocCRMgraph. These hashtags will help focus communication within the museum and broader LAM tech communities specific to these important emerging topics."

In addition to rallying interest in #cidocCRM-driven development within the museum informatics community, FactMiners will increase its outreach activity to engage the Neo4j and broader graph database communities in the exploration and development of a "full graph" implementation of the #cidocCRM.

FactMiners will also engage Neo Technology, the Structr folks, and vendors in the graph visualization community, like KeyLines, to join us in making a contribution to the global cultural preservation movement by working together this year to create a new Neo4j/Structr-based replacement for the www.CIDOC-CRM.org community website. This site is used as a central repository for the #cidocCRM model and its various information resources and news about this ISO standard metamodel. As new developers embrace the #cidocCRM, the community website will be increasingly important. An interactive Neo4j and Structr based site with "live document" visualizations and cross-referencing for the #cidocCRM metamodel will be an ideal way to showcase our web, app, and visualization technologies while making an important contribution to global cultural preservation.

"2015 looks to be the year that the CIDOC-CRM gets a real 'shakedown cruise' as a broader community of software designers and developers begin to explore and use this valuable resource within the cultural heritage community." Salmons said, "And FactMiners is happy to be a part of these exciting developments in the evolution of Internet and its use in the preservation and transmission of our cultural heritage. Keep up the great work CIDOC-CRM SIG! Full speed ahead #cidocCRMdev and #cidocCRMgraph!"

Our #MCN2014 Presentation Exploring Metamodel Subgraphs - GraphGist Edition

Jim Salmons — Tue, 30 Dec 2014 18:14:48 +0000

We invite you to view the Neo4j-based "GraphGist Edition" of our recent #MCN2014 presentation about FactMiners and The Softalk Apple Project at the annual conference of the Museum Computer Network.

We again thank the Museum Computer Network Association and PICTION for sponsoring our Emerging Professional scholarship that enabled Jim Salmons and Timlynn Babitsky to attend the conference on behalf of our projects to learn, network with Kindred Spirits, and make our presentation to the museum technology community. The opportunity to attend this excellent conference was phenomenal and will be a source of enthusiasm and inspiration for our continued evolution of our grassroots Citizen Science/History projects.

What is the GraphGist Edition?

In the Open Source developers' world and most notably in the GitHub.com community, a gist is most usually written as a convenient document-based "how-to" or helpful short explanation about a useful snippet of programming code or a programming design or method that can be served in a "live example code" format. Folks interested in Python write Python-based gists, Ruby folks do Rudy-based gists, and so on.

In the Neo4j community, we have an incredible learning/sharing "live document" format called a GraphGist. The Neo Technology documentation team developed this clever server-based technology and documentation format standard to facilitate exploring and sharing ideas and techniques using Neo Technology's Open Source Neo4j graph database.

By writing to this standard and serving your GraphGist through the freely available gist.neo4j.org server, a writer can explore Neo4j's Cypher query language by showing and explaining queries that are then run server-side with the results being dynamically visualized in your browser view of the GraphGist. This document technology is obviously valuable for communicating to others in teaching and explanatory contexts. But GraphGists are also useful as an incredible self-learning and project-design documenting resource.

My #MCN2014 presentation includes a section that summarizes the core ideas of the metamodel subgraph design pattern. The "Where Facts Live" - Exploring the Metamodel Subgraph of a FactMiners Fact Cloud: GraphGist Edition provides a "live document" version of the four Cypher queries that I used to build the basic structure of a metamodel subgraph of Softalk magazine during my #MCN2014 presentation.

For those who may be interested in additional details and a "Hello, World" scale introduction to how a metamodel subgraph can be used for computational analytics as part of an Open Culture cognitive computing platform, see this two-part GraphGist on the metamodel subgraph pattern and this "Rainman/Sherlock" piece exploring the cognitive computing aspects of our project's mission.

Our FactMiners & Softalk Magazine Presentation at #MCN2014

Jim Salmons — Wed, 03 Dec 2014 02:37:42 +0000

We invite you to view the "Lively Talkin' Slide" Edition of our recent presentation about FactMiners and The Softalk Apple Project at #MCN2014, the premiere museum informatics conference. We again thank the Museum Computer Network Association and PICTION for sponsoring our Emerging Professional scholarship that enabled Jim Salmons and Timlynn Babitsky to attend the conference to learn, network with Kindred Spirits, and make our presentation to the museum informatics community. The opportunity for growth of both our projects was phenomenal and will be a source of enthusiasm for our continued evolution of these grassroots Citizen Science/History projects.

Thoughts on CIDOC-CRM Classes: "Oops, who put all this Time Stuff in my Box of Things!?"

Jim Salmons — Tue, 04 Nov 2014 21:08:40 +0000

I am using the CIDOC-CRM – the Conceptual Reference Model developed by the International Council of Museums – as the primary domain reference model guiding design and development of the FactMiners social-game platform. In a recent post I looked at the Conceptual Reference Model from a "pure graph" perspective, re-imagining the CRM's Property Declarations as "just another" labeled subset of model elements, that is, as just another important subset of CRM Classes. In this post, I explore the "entity-ness" of the CIDOC-CRM Class Declarations.

Oops, We've Got a Lot of Time 'Stuff' in Our Box of Things!?

The approach I am taking on the design of the FactMiners platform is leveraging the expressive and flexible power of today's graph database technologies. This solution technology encourages me to look at the CIDOC-CRM as much as possible from a "full graph" expression. In addition to this graph-based interest, I believe my personal experience contributes a unique perspective in working with the CIDOC-CRM.

Twenty-odd years ago I was a thought leader and designer/developer in a "skunkworks" doing "executable business model" software frameworks in Smalltalk as part of the Object Technology Practice of IBM Global Services. Through this work we did groundbreaking work "objectifying" Process, using an agent-based perspective, and driven by strict adherence to a rather simple but powerful role-actor metamodel. A "smart desktop" framework dynamically generated "application" views on the executing business model. Change the business model and the "applications" dynamically changed. We had an opportunity to "troll" the IBM Global Services consulting practices looking at their IRMs – their Industry Reference Models. We were looking for other practice collaborators who had a decent IRM and customers who might be interested in, or better yet, need exploratory business modeling services.

So when I looked into the "pile of stuff" that is the CIDOC-CRM, I had a whole lot of context and tactics for sorting stuff out and "seeing" what's there. Recently, as I poured over the CRM Definition with an eye toward importing the Property Declarations into a Neo4j graph database, I had some "A-ha!" Moments where I think I see what might be the biggest source of frustration folks have when trying to "dip into" (that is, to explore and understand) the CIDOC-CRM.

One of the distinguishing characteristics of the CIDOC-CRM is its "object-oriented" foundation. The OOP influence in the expression of the CIDOC-CRM is significant and useful. However, I believe that a less-technical reader will not see – or worse, justifiably be confused by – the important OOP-modeling distinction between "Thing objects" and "Activity objects" – to use the most general of Class names found in the E2 Temporal Entities and E77 Persistent Item branches of the class hierarchy.

Objectifying process as a first class object is a rather subtle OOP technique with significant implications. The current CIDOC-CRM Definition text document, the on-line class hierarchy diagram, and the various subsystem diagrams seriously underplay this important design distinction. I believe that if the official CRM Definition text and associated graphical diagrams more fully "set the stage" for understanding the importance and utility of this underlying "Big Picture" nature of the CRM, the motivated exploratory user might have a more successful experience.

Let's Take A Quick Look...

As you can see in the following screenshot collage, the official 'Definition of the CIDOC Conceptual Reference Model' presents the CRM Class Declarations as a prefix-sorted master list. The Modelling Principles section jumps immediately into some very deep and subtle distinctions of monotonicity, disjointness, extension, etc. while overlooking this considerable distinction between the E2 Temporal Entities and E77 Persistent Item branches of the hierarchy. Only two summary lists visually show the deeply indented hierarchies of both the Class and Property Declarations. And the explanation of this significance is barely discussed.

What jumps out at you is that the current CRM Definition document does a great job of being the 'Volume 2. Reference' of a two-volume set where the first volume provides the Big Picture perspective and example-based Getting Started material. This "missing volume" is a necessary complement to the strict "just the facts" Definition reference. Unofficial community contributions help to fill this void – notably, e.g., Dominic Oldman and the CRM Labs' "CIDOC-CRM: Primer V. 1.1" (PDF). However, the official www.CIDOC-CRM.org provided reference documents should include such a complementary introductory volume as part of the Definition set.

This "missing" introductory volume of the CRM reference documents would surely incorporate graphical diagrams similar to those currently available on the official CIDOC-CRM.org website. But a quick look at the available diagrams – as hard as I know it was to create and produce them them – confirms that the current resources dramatically underplay this important distinction between Thing Objects and Process (Temporal) Objects.

The current text reference and class hierarchy diagram do little to highlight the important distinction between the significant partition of the CRM model elements into 'Thing Objects' and 'Process Objects'.

The situation doesn't become any clearer when we look at the numerous subcomponent model diagrams on the CIDOC-CRM.org website. Again, I know how hard it was for someone to draw and validate these images. These diagrams are super helpful as far as they go. But their format seems more constrained by the diagram drawing tool used rather than there being an explicit model diagramming standard driving the current diagram presentation format.

Here, for example, is the Object Association Information component diagram. I picked this as it is relatively sparse and includes a good mix of 'Thing Objects and 'Process Objects.' This part of the model explains how Things and People can be found at certain Times in specific Places participating in discrete Events, etc.

The physical arrangement and IS_A superclass relationship double-line arrows reflect this Thing/Activity distinction among the CRM model elements, but this is a very subtle visual distinction. And as with all the current component diagrams on the official website, this diagram is a static image. There are no interactive links between the graphical Class nodes and Property edges and their respective entries in the official Definition text.

My own frustration at diving into and around the www.CIDOC-CRM.org on-line reference material has encouraged my desire to contribute an updated and more interactive reference resource for the model to the CIDOC-CRM community. Such a more exploratory resource could be a step-wise generalized contribution of our project beyond the specific focus of our work on the FactMiners platform. Here, for example, is what I did to explore some potential along these lines...

I started with a fresh copy of a Neo4j graph database with the Class Declarations as nodes and Property Declarations as relationships (between nodes). (The GitHub for this 'seed' of CIDOC-CRM model elements in a Neo4j database is here.)
I did a Cypher query to add a 'Persistent' and 'Temporal' label to each class based on its membership in the E77 or E2 branch of the class hierarchy.
I then did a query in the stock Neo4j browser to return and visualize the model elements (CRM Entities) associated with the Object Association Information component.
I next dragged the nodes of the "bouncy ball" browser graph visualization to more closely resemble the static diagram of the target diagram.
Finally, I clicked on the E7 Activity node to pop up its node properties (not to be confused with CRM Properties) to show how the full CRM Definition entries are in this Neo4j database... and then I did this screenshot.

While this stock browser visualization is too "one-off" to be truly useful, this does show the impact of something as simple as subset coloration (or other containment revealing visual queue) to help reveal the underlying design of the CRM model elements. And although the static nature of the screenshot does not reveal it, the ability to examine full Definition entries within the exploratory diagram is another step in a good direction to consider for the official CIDOC-CRM documentation and its companion website. If this much functionality can be gained from one-off use of available generic tools, imagine what we could accomplish by building a CIDOC-CRM reference resource with a full RESTful and public web interface built on a platform based on Neo4j + Structr + KeyLines (or Alchemy.js, Linkurious, or similar client-side visualization layer).

Exploratory Decomposition of CIDOC-CRM Graphical Diagrams

Continuing our thought experiment imagining an expanded set of CIDOC-CRM reference documents, I would encourage an effort to encapsulate the important structural design distinctions through a logical/functional "exploratory decomposition" graphical style. I simply don't have all the answers as to what this means fully, but I can provide an example based on my own thought experiment along these lines.

I mentioned that my prior "executable business model" experience was helpful to my understanding of the CRM. I also mentioned how the Smalltalk framework we built was agent-based, objectified Process, and was based on a "ruthlessly simple" top-level metamodel. I took a UML (Universal Modeling Language) Class model that is very similar to what we did in that Smalltalk skunkworks, and I overlaid the high-order CRM Entities that have an obvious model element alignment with this process-oriented UML Class model.

At one level, this diagram looks too simple to say all that much about a non-trivial software architecture. But appearances are deceiving when it comes to such software design diagrams. This UML diagram says a LOT about an agent-based role/actor software architecture. And having written software frameworks implementing such architectures, I know that the beauty and the "devil" is in the details suggested by such high-level diagrams. I know, for example, how extensive the OOP-programming decomposition of the Activity and Task objects can be to implement the required interfaces and functions of such a high-level diagram. Yet as complex and diffuse as the implementation decomposition of these high-level model elements may be, well-linked logical decomposition of such inter-linked diagrams of the full model can keep the reader in context to avoid confusion or misunderstanding.

This "Just Enough, Just In Time" exploratory presentation style is how we need prospective CIDOC-CRM users to be exposed to the full CRM model. We need a rich set of interactive diagrams that keep the reference-reader "in the moment" and in context. A "double-click dive" into the E7 Activity node, for example, would reveal the decomposition of Activities into the various modeled elements including E11 Modification, E10 Transfer of Custody, E86 Joining, E87 Leaving, E79 Part Addition, etc. In each case, a context-retaining diagram specific to the "leaf" class being investigated will not only be helpful for general model learners, but will be invaluable for software architects intending to use the CRM as a metamodel constraining a full system instance design.

I believe that there are far more developers today who are "comfortable users" of object-oriented programming technologies than there are those who are comfortable with designing and building systems based on advanced OOP architectures, especially ones that objectify process. For this reason, I believe that many mainstream programmers would find the current model reference resources insufficient to design and build full CIDOC-CRM based systems. Not that it can't be done... just that there would necessarily be a lot of "private mental concept transformations" required to get the job done.

Given this belief that there are more casual users of OOP technology than there are advanced OOP designer/developers, the proposed "missing" first volume of the CIDOC-CRM Reference documents should be envisioned as a Developer's Guide to CRM-compatible system design and programming. The non-technical/non-developer would find the overview and Big Picture content of such a guide useful. An exploratory learner can simply stop his or her reading of this introductory guide once the information goes deeper than needed for the learner to collaborate as a subject matter expert on a team developing such systems, or to assess the model when making a recommendation about possible adoption of the CRM by the prospective user's institution. Such a proposed Developer's Guide, however, would provide an invaluable "easy on ramp" for software architects and developers tasked with building CRM-compatible systems.

At this point, I can't go further without some non-trivial time and effort to provide additional specific examples of where we could go with CIDOC-CRM reference documentation. I do believe, however, that this post already sufficiently suggests why we might want to do this and how this effort might be approached.

As always, I appreciate comments and questions,
-: Jim :-

Thoughts on a Graph Representation of the CIDOC-CRM: Property Declarations

Jim Salmons — Sun, 02 Nov 2014 00:12:09 +0000

I am having an interesting time looking at the CIDOC-CRM – the Conceptual Reference Model for museums developed by the International Council of Museums (ICOM). In particular, as generally described in my last post, I am looking at the CIDOC-CRM with a "pure graph" lens on a metamodel developed with an object-oriented perspective.

The interesting part of my exploration has to do with bringing the "ruthless simplicity" of a graph expression to the interpretation of the CIDOC-CRM for the purpose of representing it as a Referenced Model within the metamodel partition of the graph database as part of the FactMiners' Digital Humanities-based social-game platform. I've written two complementary Neo4j-based GraphGists that explore the design pattern of an "embedded metamodel subgraph" as a means to build a fine-grained "Fact Cloud" of the referential content of the 48-issue collection of Softalk magazine covering the early history of the microcomputing revolution.

In this post, I'll take a first look at how CIDOC-CRM Property Declarations can be beneficially cast as "First Class Citizens" (AKA Nodes) in a graph model of the CIDOC-CRM. I am still in the very early stages of CIDOC-CRM exploration, so take these observations as public research notes.

The Challenges and Potential of the CIDOC-CRM

An interesting dimension of the CIDOC-CRM is that it intentionally tries to be a comprehensive conceptual model (AKA a metamodel) for not just museum artifact description, but to cover the active process of artifact curation and preservation as well as broader realms of collection management, etc. In this sense, the CIDOC-CRM goes where most cultural artifact ontologies rarely go, that is, into the realm of incorporating process along with structure-oriented model elements from which to construct our CRM-compatible model instances.

That's what a Conceptual Reference Model or metamodel is used for, at its most basic level. It's a set of model elements (parts to build a model out of) and a set of instructions that constrain how you can put these parts together. Through this model, we can share an understanding about what some domain of activity and expertise is about. That understanding is to be used, in our case, to design software systems to implement this shared conceptual (mental) understanding of what needs doing and how to do it. (I know this is not the only reason for having a comprehensive conceptual reference or metamodel, but it is the compelling reason for this exploration and discussion.)

As is often the case, industry reference models are rarely used to drive down to the granularity of "executable" in the sense of software being designed strictly to the, let's call it "semantic expressibility" of the metamodel. In other words, these conceptual reference models are most often used loosely to guide human-to-human ("mind-meld") conversation and modeling-based decision-making. But there is a lot of room for what are in effect "uncontrolled individual model transformations" (AKA we developers think about how to implement the model and then write some code that approximates our personal understanding of this shared vision). So if during implementation of metamodel-driven design there are "gotchas" or logical inconsistencies or just plain "temporal anomalies" (a big model done by committee over a long period of time), these issues are not too often show-stopping problems as we "one off" resolve these issues by "coding band-aids" as we go along.

But one of the goals that the CIDOC-CRM SIG group members aspire to encourage and support is research-based inference and deductibility – text- and image-based computational analytics – for CIDOC-CRM compatible datastores and associated #LODLAM web services. In other words, "close enough for horseshoes or hand grenades" may be good enough for many cases of using a conceptual reference model for indirect reference, but this is not good enough if we are going for fact- or inference-discovery and validation via metamodel-constrained computational analytics.

So let's look at the most obvious case in point; Property Declarations as "faux" relationships between CRM Classes.

CIDOC-CRM Property Declarations as "Shortcut" Classes

A typical CIDOC-CRM graphical diagram of key parts of the model shows the graph-based shared understanding of how we're "thinking about" this museum conceptual model. The "object"-like things are drawn as nodes and have "E-prefix" names that reflect their "IS_A" (object-oriented inheritance) descent from the "E1 CRM Entity" root of the CIDOC-CRM Class Hierarchy. The relationships (or edges in a pure graph sense) between Classes (AKA our graph-based Nodes) are defined as CIDOC-CRM Properties. CIDOC-CRM Properties have a "Pnum-prefix" name and have the additional facet of "bidirectional/reflexive naming" -- e.g. P67 "refers to/is referred to by" providing the appropriate human-readable interpretation of the named relationship based on which "end" of the relationship you want to anchor your mental understanding of the described relationship.

To understand how this current view on the CIDOC-CRM is problematic to a "pure graph" expression, let's look at a particularly interesting cluster of CIDOC-CRM model elements (both Classes and Properties) that describe the "Image Information, Objects and Carriers". I've highlighted the aspects of this diagram of the CIDOC-CRM definition that cannot be expressed in a basic graph representation.

This subset of CIDOC-CRM model elements is especially interesting as it gets to the core of our FactMiners' design interest – and that is, "piercing the veil" to move our Fact Cloud coverage from artifact description to deep analysis by modeling the artifact's representational meaning. In our case, we require a metamodel sufficient to cover the complex structure of a commerical magazine while providing the granularity to model – based on CIDOC-CRM-compatible form – the 48 monthly snapshots of the cacophonous "Open World" of activity at the dawn of the Microcomputer Revolution as depicted in the incredible content of this historic magazine archive.

The eagle-eyed "graphistas" among you will notice a show-stopping gotcha. Those double-line arrows from relationship-to-relationship violate the essential "ruthless simplicity" of a pure graph model. A graph is just nodes and relationships, with relationships being the edge/line links BETWEEN nodes. There are no relationships between relationships in basic graph theory.

Fortunately, this is not a show-stopping problem. It just suggests that the view we're given is more a "mental shortcut" for a graph expression that models the relationship as a distinct type of Class. In this way, a "node-ified" CIDOC-CRM Property can be modeled with respect to its "IS_A" subproperty/superproperty relationships as well as support the "Pnum.1" idiom where property specializations can be expressed through "mode of X" relationships to "E55 Type" entities, etc.

In other words, here is how we can look at a portion of the "Image Information, Objects and Carriers" model with "node-ified" CIDOC-CRM Property Declarations:

In this diagram, the "subset-membership containment areas" are a visualization of, in Neo4j graph database-terms, a label-based conceptual type. That is, our metamodel of the CIDOC-CRM contains Nodes that are of type "CRM Class" and a collection of Nodes of type "CRM Property." These two labeled subsets are emphasized in the graphic by node color in addition to their containment in subset-membership labeled boxes.

Now that we have a "node-ified" Property "P138 represent/has representation" represented in our graph as a node, we can create its "subproperty of" relationship to "P76 refers to/is referred to by." This "subproperty of" relationship, by the way, can be thought of as a specialization of the "IS_A" relationship underlying the object-oriented CIDOC-CRM Class subclass and superclass inheritance relationships. Note, too, that we can easily create the "Pnum.1" relationships that provide specialization of a CRM Property.

[Note: The above diagram is decidedly high-level. A full rendering of a "pure graph" expression of the CIDOC-CRM would show labeled domain/range relationships, cardinality, etc. These fine-grained aspects of the model are left off here to keep the explanatory diagram cleaner.]

Okay, but so what? Why "node-ify" CRM Properties?

At some level we could think, "Okay, so what?" Aren't we just nit-picking over the details of the metamodel representation for communication and system design discussions. For many, yes, that's true. But the FactMiners LAM-based social-game platform is being designed with an underlying cognitive computing perspective. We need our metamodel expression of the CIDOC-CRM to be machine-executable.

This aspiration for deep computational analysis of cultural artifacts is also one held by members of the CIDOC-CRM Special Interest Group. Dominic Oldman – a CIDOC-CRM SIG member, Principle Investigator of www.ResearchSpace.org, and IT exec of The British Museum – writes in the latest version of "The CIDOC Conceptual Reference Model (CIDOC CRM): PRIMER" (my emphasis added):

"The most important kinds of computer-based reasoning the CRM can support are generalisations of relationships and deductions from highly indirect relations such as what parts have in common with their wholes, what wholes inherit from their parts and what is transferred across meetings and processes of derivation. These are not meant to replace scholarly conclusions but to comprehensively detect facts relevant to answer research questions. Besides others this ensures that highly specialized knowledge stays accessible to generic questions regardless the specificity of representation."

My belief is that a fully-realized graph expression of the CIDOC-CRM will not just support the kind of "fact-checking" and discovery that Dominic asserts in the quote above, but will move CIDOC-CRM-based computational analytics into the realm of significant first-class, fine-grained, traceable, interpretive scholarship that is only just beginning to be imagined based on the rapid advances in Deep Learning, Natural Language Processing, Image Scene Recognition, and other aspects of the explosion of advances in what is being loosely corralled by the term "Cognitive Computing."

While my example is ruthlessly simple for the purpose of introductory explanation and is not CIDOC-CRM-specific, the first part of my two-part GraphGist demonstrates how generalized query-based fact discovery and validation can be performed on a "self-descriptive" Neo4j-based graph database. And closely related to this GraphGist is the research agenda described in my "Rainman Meet Sherlock" post.

I welcome your thoughts and/or questions.

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

Jim Salmons — Sat, 25 Oct 2014 19:13:04 +0000

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.

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.

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.

Inside the FactMiners' Brain - Rainman Meet Sherlock

Jim Salmons — Sun, 31 Aug 2014 17:27:22 +0000

NOTE: In case you missed it, here is a link to a screencast of Kenny Bastani's webinar about using the Neo4j graph database in text classification and related Deep Learning applications. It's a fascinating introduction to some original work Kenny is doing that leverages the strengths of a property graph, in this case Neo4j, to do some Deep Learning text-mining and document classification.

This article is about what we are going to try to do with Kenny's new Graphify extension for Neo4j. And a big "Thank you!" and kudos to Kenny for kickstarting activity around this important topic within the Neo4j community.

Some Thoughts About Thinking

You would be hard-pressed to go through any formal education where you did not learn about our "two brains" – left and right hemispheres, verbal/non-verbal, creative/literal, the conscious/subconscious, long-term/short-term, self/other, etc. All these various perspectives remind us that how we think, as humans, is a complex yin-yang cognitive process. Whatever works well to help us understand ourselves and the world around us in some cases, does poorly helping us in others, and vice versa. So we've cleverly evolved the "wetware" to do both and, in one of our brains' most truly amazing feats, to provide some kind of highly effective, real-time integration of the these multiple perspectives.

One of the most intriguing distinctions to consider when attempting to model human cognitive processes (let's settle for calling it "smart software" to avoid going too far into pure ResearchSpeak) is to look at the role of subconscious and conscious processing. Some things are either so voluminous and detailed -- basic perception, for example -- that we would bore ourselves to death and slow our thinking processes to a crawl if they ran through our conscious, mostly verbal, cognitive processes. Some other aspects of our thinking -- e.g. things that produce an "A-ha!" conscious moment of discovery -- require the "hands off" focus of subconscious processing. Without such cloistered incubation opportunities, our overbearing conscious mental processes can too easily derail an otherwise breakthrough thought.

So it should not surprise us that software analogs of (something akin to) our own cognitive processing will benefit from providing a similar strategy of "complementary opposites." We should expect to find some real design opportunities for "smart software" by providing a rough approximation of this subconscious/conscious distinction as we move from an application-centric development mindset to a more appropriate agent-centric design mindset. Exploring how smart software might incorporate this "two-cyclinder thinking engine" is one of the "serious fun" R&D initiatives at FactMiners.org.

We're active in the Neo4j community because FactMiners is exploring the unique, expressive nature of graph database technology to model both how "subconscious" cognitive processing (e.g. the NLP-based stuff of Kenny's text classification webinar) can be integrated with "conscious" cognitive processing (e.g. our metamodel-subgraph GraphGists that are more akin to "mind maps"). Our belief is that such a software design strategy can lead to a synergistic result that is greater than the sum of what these simulated cognitive processes can contribute independently. To allude to popular culture, our research asks:

How can we get both the Rainman-like, obsessive-compulsive, bureaucratic, ruthlessly-detailed part of our subconscious processing to work in concert with the Sherlock Holmes-like, logical, deductive, constructive part of our "wetware"?

The Rainman Part - Kenny Bastani's Text Classification Blog/Webinar

Kenny Bastani's webinar this Thursday, "Using Neo4j for Document Classification" will provide a great live demonstration of the kind of relentless, detail-oriented, largely subconscious aspect of our human cognitive process. Kenny's recent blog post, "Using a Graph Database for Deep Learning Text Classification," is provided as a webinar supplement and gives a good introduction (with links) to the Deep Learning ideas and methods employed in his latest Open Source project, Graphify.

Graphify is a Neo4j unmanaged extension adding NLP-based (Natural Language Processing) document and text classification features to the Neo4j graph database using graph-based hierarchical pattern recognition. As Kenny describes in his blog post:

"Graphify gives you a mechanism to train natural language parsing models that extract features of a text using deep learning. When training a model to recognize the meaning of a text, you can send an article of text with a provided set of labels that describe the nature of the text. Over time the natural language parsing model in Neo4j will grow to identify those features that optimally disambiguate a text to a set of classes." (Kenny Bastani, full post)

When you read the rest of Kenny's blog post you will get a very quick and informative introduction to the Vector Space Model for Deep Learning representation and analysis of text documents. The algebraic model underlying Kenny's Graphify Neo4j extension is just the kind of Rainman-like, obsessive, detail-oriented processing that is representative of the subconscious side of our cognitive processing.

If you read the above description of Graphify closely, you will see the opportunity for synergy and integration between Graphify's "subconscious" processing and the more "conscious" processing reflected in my GraphGists exploring the "self-descriptive" Neo4j graph database.

The Sherlock Part - FactMiners' Metamodel Subgraph GraphGists

Imagine if you were able to sit down for tea with the fictional Sherlock Holmes. We hand him a paper and pen, and then ask for a description of the particulars of his latest case. Sherlock would surely resort to sketches in the form of a graph diagram or something easily mapable to a graph representation. Graph semantics are "elementary" and flexibly extensible -- properties that Sherlock would surely appreciate.

I started exploring this "conscious" cognitive process side of graph database application design in the first two parts of my GraphGist design document series, "The 'Self-Descriptive' Neo4j Graph Database: Metamodel Subgraphs in the FactMiners Social-Game Ecosystem." In the longer and more detailed second part of this GraphGist, I explored how an embedded metamodel subgraph can be used to model a "Fact Cloud" of Linked Open Data to be mined from the text and image data in the complex document structure of a magazine. In our case, we'll use FactMiners social-gameplay to "fact-mine" a digital archive of the historic Softalk magazine which chronicled the early days of the microcomputer revolution. In this regard, our "sandbox-specific" application is museum informatics. However, there is nothing domain-specific about the solution design we are pursuing.

With this more general application in mind and in looking for that opportunity where Sherlock can work hand-in-hand with Rainman, it is the first part of this GraphGist series that is the more relevant to the "whole brain" focus of this post.

In this first part of my GraphGist, I provide a "Hello, World!" scale example of how a graph database can be 'self-descriptive' to a layer of smart software that can take advantage of this self-descriptive nature. In this gist, I had some fun exploring the old aphorism from Journalism school, "Dog bites man is nothing, but man bites dog, that's news!"

In brief, the assumption is that a 'self-descriptive' database is 'talking' to something that is listening. Under this design pattern, the listening is done by a complementary layer of "smart software" that can use this information to configure itself for all manner of data analysis, editing, and visualization, etc.

In the case of the ultra-simple "Man bites Dog" example, the layer of smart software is nothing more elaborate than some generalized metamodel-aware Cypher queries. Cypher is the built-in query language for Neo4j. In my gist example, these queries are used for "news item" discovery and validation. By simple extrapolation you can readily imagine the level of "conscious" processing that could be brought to bear to "think about" the data in a 'self-descriptive' graph database.

With this much overview of the "subconscious" and "conscious" aspects of our FactMiners' brain, we're ready to look at that opportunity for integration... that place where Rainman meets and works with Sherlock.

How Rainman and Sherlock Might Work Together

There is a strong hint at how the Deep Learning "subconscious" processing of Kenny's Graphify component might fit into the "brain model" of FactMiners. I'll underline the bits in this quote from Kenny's article to suggest the integration opportunity: "Graphify gives you a mechanism to train natural language parsing models that extract features of a text using deep learning. When training a model to recognize the meaning of a text, you can send an article of text with a provided set of labels that describe the nature of the text..."

Graphify just needs to be fed a list of those "text nature describing" labels and a pile of text to dive into and away it goes. I believe an excellent source of this "text nature knowledge" -- those labels needed to seed the training and data extraction of Kenny's "subconscious" Rainman-like text classification process -- those labels are very explicitly represented, maintained and extended in the information encoded in, and organized by, the metamodel subgraph of a 'self-descriptive' graph database.

We should be able to establish a feedback loop where Graphify's label list is supplied by Sherlock's "mental model" in the metamodel subgraph, and Graphify's results are fed back to refine or extend the metamodel. How, even whether, this will all work as envisioned we will discover over the weeks ahead.

Next up? We're looking forward to Kenny's webinar and to having some serious fun digging into Graphify.

CIDOC-CRM Meet METS/ALTO - A Recipe for FactMiners 'Fact Clouds'

Jim Salmons — Thu, 24 Jul 2014 19:23:56 +0000

FactMiners.org is very pleased to announce that we are adopting METS/ALTO as the "drill down" metadata and file/data format specifications that will guide our DSL (Domain Specific Language) extensions of the CIDOC-CRM as part of the design of the Open Source FactMiners LAM-based social-game platform.

The CIDOC-CRM is the ISO standard Conceptual Reference Model of the International Council of Museums (ICOM). As such, it has both metadata coverage as well as metamodel coverage of collections management process/workflow dimensions that are absent from more ontologically-focused metadata specifications.

FactMiners.org will use the CIDOC-CRM for guidance in designing the underlying digital collections management aspects of our platform while incorporating METS/ALTO metadata standards and applying best practices from its user community as we "piece the veil" to model the representational meaning (AKA "mine the facts") of an artifact/object. METS/ALTO will be especially key to providing the "article-level segmentation" needed to effectively model the complexity of our first digital archive, The Softalk Apple Project.

We are so excited to learn about the Library of Congress' "Chronicling America" program and website, along with affiliated LAM projects like the California Digital Newspaper Collection. We now have a good handle of how to proceed with our DSL extension of the CIDOC-CRM as explored in our award-winning Neo4j GraphGist: The "Self-Descriptive" Neo4j Graph Database: Embedded Metamodel Subgraphs in the FactMiners Social-Game Ecosystem.

Together, METS – the Metadata Encoding & Transmission Standard – and ALTO – Technical Metadata for Optical Character Recognition – give us an excellent roadmap and supporting technologies with which to drive the "last mile" of granularity whereby CIDOC-CRM-based collections management and preservation micro-tasks (AKA FactMiners gameplay) can be performed on the digital object's article-level content. FactMiners' elemental facts will be most meaningful when discovered and validated within an article-level segmented digital preservation object as the FactMiners "playing field".

With this new piece of our roadmap puzzle falling into place, we have a very good idea of how to revise Part 2 of our GraphGist about modeling the Softalk Magazine archive collection. So... full steam ahead! :-) More as it shapes up.