All,
I think a few comments and a link to a diagram can provide some clarifying context. This is a very specific situation where my prior early-to-mid 1990s experience developing Smalltalk-based “Executable Business Model” (EBM) frameworks based on an actor-role-task metamodel is helpful (and almost certainly unique within this group). It is not the case that the #cidocCRM is to be executable _itself_. Rather, as a metamodel it is used as a constraint against the design of metamodel-compliant “Social Machine parts” from which INSTANCES of compliant executable models are buildable. The compliant instances are executable, not the metamodel from which the instance is derived. In other words, the #cidocCRM tells us the _model elements_ from which we can build an executable instance, but it is our _selection_ of, and _recipe_ for putting together, these selected elements which creates an executable instance. For example we might say, “To create the Sagging Walrus Museum collection management system we take 5 of ‘these’ piece parts, 2 of ‘those’, create new ones called ‘this’ and ‘that’ which descend from ‘some other’ metamodel element.” These new domain-specific extensions guarantee that they will comply to required metamodel element interfaces while internally performing some new unchartered instance-specific activity that is the Sagging Walrus way of doing things. Once we have this collection of model elements and put them together in a certain configuration, that _instance_ is executable and traceably compliant to its metamodel although the metamodel itself is not directly executable. The execution comes from the S/W frameworks we write that are compliant to the metamodel. I cite, for example, this draft model which is part of the @FactMiners design wherein I have “roughed in” #cidocCRM model elements into a UML-based metamodel that says a lot about how to acceptable put these #cidocCRM elements together: <http://goo.gl/1jhh1Q> http://goo.gl/1jhh1Q. The #cidocCRM elements themselves don’t tell us much about their execution. We get that clarity by putting these elements in the context of a recommended actor-role-task executable “harness” which, I might add, is implied by these elements’ names and descriptions. The actor-role-task “harness” is what gives us the ability to move from ontological/descriptive use of the #cidocCRM model, to using it as a “Social Machine” blueprint for generating #cidocCRM-compliant system instances. I believe that #cidocCRM microservices frameworks could be an ideal “easy on ramp” for widespread adoption of the #cidocCRM as LAMs large and small wrestle with life in the emerging Linked Open Data world. For some, these frameworks will be used to generate whole-system replacement through system migrations. Others will simply wrap or extend existing systems using these frameworks. All this said, the “unknown new territory” nature of #cidocCRM microservice frameworks is also why I recommended the “community skunkworks” approach to this exploration so as not to derail or detract from the progress being made on the current new website project at FORTH. Done in parallel, we could get some real synergy as one project informs/reacts to the other through shared experience and communication. I believe the most useful thing we could do is simply have Martin’s new website team put its requirements doc and any other helpful design documents together with new system code to date in a GitHub or similar repository where we can fork, explore, and feedback to each other. Happy-Healthy Vibes, -: Jim :- From: martin [mailto:[email protected]] Sent: Sunday, May 17, 2015 1:51 PM To: Sebastian Rahtz; Jim Salmons Cc: Dominic Oldman; [email protected] Subject: Re: [Crm-sig] Why #TEI P5 as format-of-record for #cidocCRM Definition document On 17/5/2015 9:22 μμ, Sebastian Rahtz wrote: I would note, however, that the CRM is an abstract ontology which is only relatively recently concerning itself with “implementation”, so let’s not get _too_ carried away with the CRM executing iself - it’s not a bit of software, after all. Well, I'd regard that a misunderstanding. The S/W we need is to manage highly cross-correlated editing with logical constraints, not "executing the CRM". However, the CRM was always meant for implementation. The immediacy or not of RDFS/OWL versions is for me not fundamental to implementation, and yes, the CRM is data structure, not S/W, equal to data dictionary definitions and UML and all the stuff of the past. Indeed, on SIS-TELOS CRM did run as database from its conception. I wrote the core code myself in 1990-1994 ;-) . Best, Martin -- -------------------------------------------------------------- Dr. Martin Doerr | Vox:+30(2810)391625 | Research Director | Fax:+30(2810)391638 | | Email: [email protected] <mailto:[email protected]> | | Center for Cultural Informatics | Information Systems Laboratory | Institute of Computer Science | Foundation for Research and Technology - Hellas (FORTH) | | N.Plastira 100, Vassilika Vouton, | GR70013 Heraklion,Crete,Greece | | Web-site: http://www.ics.forth.gr/isl | --------------------------------------------------------------
