Martin,
Thank you for such an informative post! I will enjoy more deeply reading it for the valuable context and insights that will more fully inform my appreciation for the great work that the CRM SIG has performed to date, and is forging ahead upon… especially the SPECTRUM collaboration which I believe will be very beneficial to both parties. But I wanted to reply with some enthusiasm based on my initial quick read of your post. And that is to reinforce and note my appreciation for the “dual nature” of the #cidocCRM; that is, its attempt to both model its “objects of study” (the looking to the ‘past’) as well as provide modeling concepts to address that “act of study” (preservation, transfer, ownership, measurement, etc. including associated scholarship linkage/reference, etc., that is the ‘now’ of object/collection management, etc.). In response to the first Neo4j GraphGist exploring the use of a metamodel subgraph for modeling the Softalk magazine ‘Fact Cloud’ (http://goo.gl/2b6934), a Neo4j community member and now my Kindred Spirit buddy, Laurence Cook (@metacirque), tweeted that my gist reminded him of the #cidocCRM. To which I responded, “What?!” and he replied “..the Conceptual Reference Model for Museums” which I said, “Oh, THAT sounds interesting!” and long story short… museum informatics, digital humanities… who knew!? And here we are today. The thing that struck me upon my first exposure to the #cidoCRM was that “Déjà vu” feeling of “Oh man, this is not just another ontology, this is a metamodel!” based on my “executable business model” experiences. And the thing that clicked for me was closer inspection of the CRM Entity hierarchy where I saw the two big partitions of Persistent Objects and Temporal Entities. Mixed in there on the Temporal Entity side were things obviously intended to both cover the “description of the past” and “stuff we do when using this model to do work on/with the objects of the past” – that is, there were these ‘process-looking’ Entities that evoked the “looking forward” aspects of the #cidocCRM. My goal for the @FactMiners Fact Cloud platform requires both dimensions. On the one hand, I need the #cidoCRM’s expressive “looking at the past – documenting the object itself” aspect for fine-grained _document structure_ and _content depiction_ modeling capabilities. But we also want our #SmartData to be _self-descriptive_ in the sense of providing explicit information about “who can do when, when, where, and how” which is the #cidocCRM’s “forward-looking” dimension. My belief is that “smart programs work best with smart data” which is reflected in this diagram that puts the actor-role-task “process-harness” of my prior note in context: http://goo.gl/OYMESR. What this diagram shows is that the META partition – the “self-descriptive” aspect of my #SmartData graph database design – has three primary sub-partitions: META:Structure, META:Process, and META:ReferenceModels. The #cidocCRM “past/object” dimension will be used in the META:Structure partition through a DSL (domain-specific language/extension) to do fine-grained document structure and content depiction modeling. The META:Process partition is where #cidocCRM “looking forward/workflow” dimension comes into play. In both cases, I plan to use the #cidocCRM in as much of a “pure graph” form as possible so as to work at the “live whiteboard” level of human-conceptual model-understanding. And this is where the third partition of my #SmartData design comes into play, I want to push META:ReferenceModel mapping to an explicit level where we can do two things: 1) thoughtfully map our “private garden” (human-tractable) conceptual models to existing and future Reference Models such that, 2) we can perform “on demand” graph transformations of our DSL conceptual model to whatever format is needed to appropriately respond to requests coming in via RESTFUL #LOD queries. I want to stay away from the necessary “niddling detail” of such things as RDF expression until I have “on-demand harmonization” to perform. In other words, push the complexity of Reference Model expression to the “view/controller” levels while maintaining the #SmartData aspect of an inner “private garden.” (BTW, you’ll notice a slight “plug/shout-out” in this diagram to the amazing Karma project at ISI/USC: http://www.isi.edu/integration/karma/# <http://www.isi.edu/integration/karma/> . I believe Karma will/should figure into the “to-be” platform of the new cidoc-crm.org website as a means to provide downloadable, pre-configured model-harmonizing “#cidocCRM adapters” for #cidocCRM developers.) The “A-ha! Moment” I had when I saw this dual nature of the #cidocCRM – to serve both in the META:Structure and in the META:Process partitions of my proposed design – are what clearly sets the #cidocCRM apart from its peers in the ontological systems space. (Again, I am speaking from a Wolf Child perspective of only knowing what I have bumped into on my increasingly non-random walk through the museum informatics domain.) It was the thrill of this insight about the dual nature of the #cidocCRM that led me to create what is probably one of the first known instances of a #cidocCRM-based cartoon! :D http://goo.gl/gQUDXw Thank you again, Martin, for taking the time to contribute such a thoughtful post to this list while preparing to head into a “buzzsaw” of back-to-back meetings in Nuremburg addressing many gnarly issues that inevitably complicate the best intentions of model harmonization. Happy-Healthy Vibes, -: Jim :- Twitter: @Jim_Salmons, @FactMiners, @Softalk_Apple ---current focus--- www.FactMiners.org <http://www.FactMiners.org> (Open Source #Play2Learn game community) www.SoftalkApple.com <http://www.SoftalkApple.com> (first FactMiners museum/archive project) From: martin [mailto:[email protected]] Sent: Monday, May 18, 2015 8:46 AM To: Jim Salmons; 'Sebastian Rahtz' Cc: 'Dominic Oldman'; [email protected] Subject: Re: [Crm-sig] Why #TEI P5 as format-of-record for #cidocCRM Definition document Dear Jim, Very nice thoughts indeed! Let me put another perspective to that: In a way, you describe the CRM as a sort of metamodel we have seen in the past for workflow systems. These systems, like many other IT solutions, have an orientation to the future: Control, constrain, and such make precdictable the future. If this pertains to human activities and machinery controled by humans, it results in an analysis of relevant relationships humans may have to things via their activities. An application would then narrow down the constraints to even more specific subsets of interactions. A particular process instance would then add all the unlimited details of reality we can never completely record. [[ snip snip to keep post w/in size limits please see archive for full thread ]]
