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.
The CRM however was explicitly developed to describe the past, and not
even the museum processes.
It was designed to describe possible pasts in terms of relevant
relationships we can associate with
a sort of weak causality, i.e. how states of affairs have influenced
each other in the evolution of time.
The actual past has all the unlimited details of reality we can never
completely record. Our interest is
not in what we wanted to achieve, but what actually happened.
Constraints are not interesting, only global
ones we cannot avoid. On the opposite, the deviation from the idle plans
is often more enlightening.
Intention is more seen as a historical fact than as a deterministic cause.
If we see both views together, the past and the future, we indeed can
expect that the metamodel to control the future has a strong overlap
with that to describe possible pasts and to explain the flow of
influence. Even the human attempts to control the future play a role of
influence.
In the last meeting we decided to map and model SPECTRUM under the CRM.
That will be the first application of the CRM to model processes
intended to be followed.
If such applications emerge, it will indeed be exciting to see, with the
due scientific rigor, how CRM concepts cover and extend into a
intentional process world.
Altogether, what you describe here is building support for the
application discourse. We have so far targeted at that with the mailing
list and mapping descriptions. It deserves more, as you say.
Another, fairly different discourse is the evolution of the CRM and its
translations and derivatives.
It continuously questions the CRM concepts themselves. The complexity
emerges, because any local change
has consequences up and down the IsA hierarchy of properties and
classes in scope notes and examples, possibly in introductions, and
along "shortcut" paths and other reasoning constructs related to the
behavior of reality, such as space-time models we discuss now. This
creates "avalanches" of changes. Most of the time
goes into spotting the non-obvious consequences, and then writing the
prose. The automatic creation of derivatives is also not trivial due to
ever changing syntactic conventions.
This is the current target of the new Website.
Luckily, our syntax-neutral KR format of the CRM definition in MS-Word -
I mean the terms "class", "subclass" etc., not the Word binary-, has
helped us not to change format with each KR fashion. Many people seeing
this text think there is no logical model in the CRM, and then are
surprised that it is consistent when they translate it into a KR
language. These logical foundations of KR models have hardly changed
over the last decades, some change of flavors not withsdtanding. Indeed
we hide the TELOS encoding behind, because it is not standard, and
encoded KR is not suited for our target audience.
(important KR fashions: KL-One, KIF, DAML, DAML-OIL, RDF(S), OWL).
It may also be worthwhile to remind the younger among us, that Knowledge
Representation is one of the oldest disciplines of IT, and not an
invention of the semantic Web (and implementation of the CRM did not
start with RDF/OWL!!), and that there is literature in the IT journals
the Google saerching scientist has no idea about ;-) .
All the best,
Martin
On 18/5/2015 4:00 πμ, Jim Salmons wrote:
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.
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 |
--------------------------------------------------------------
--
--------------------------------------------------------------
Dr. Martin Doerr | Vox:+30(2810)391625 |
Research Director | Fax:+30(2810)391638 |
| Email:[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 |
--------------------------------------------------------------
