All, I love this discussion yet appreciate the time pressures many of you are under in preparation for the many meetings and agendas to be addressed in the coming week in Germany.
What I can say is, based on this excellent and on-going discussion, the way forward will be as "seriously fun" as it will be innovative and constructive to the evolution of the #cidocCRM and its community/ecosystem. I especially am awed by the SME (subject matter expertise, the most appropriate term I can muster from my prior years in corporate consulting) that Sebastian brings to the table. Much of my Wolf Child Blindness can be complemented by his experience and current activities. I love Sebastian's reference to Literate Programming because it reminds me of my 20+ years in hardcore Smalltalk design/development. The "Golden Years" of Smalltalk -- before C++ failures morphed into face-saving Java Worship -- were years spent in programming Nirvana. Smalltalk is total immersion Literate Programming. But what is more relevant to this is Smalltalk's "eating its own dogfood" nature. Other than its minimalist bootstrap to get going (and as much of that that could be replaced by Smalltalk once it was "self-sustainable") is that Smalltalk was written and executed "literally" in an image-based simulation-engine (to give it a "Mirror Worlds" connection). And that is the "self-improvement" leverage I think we have here with the bundling of a #TEI "format of record" initiative with the new website and its on-going maintenance initiative. I propose that it would be extraordinarily helpful to the #cidocCRM itself, and to our community/ecosystem, if we were to "eat our own dogfood" and officially declare the #cidocCRM Definition document as an 'E73 Information Object' and that we encourage a "community skunkworks" to use the #cidocCRM as an executable metamodel with the goal to develop an Open Source #cidocCRM-compliant microservice pipeline that will, when credibly able to, then be used to maintain, extend, support, and promote #cidocCRM use. As I write this, I see that Karl Grossner has weighed in with helpful relevant comments, and I concur with his comments, especially with regard to "salable" funding rationale. As I was working to "birth" my #cidocCRM/#TEI Personal Learning Network, one of the hopefully helpful points I made in our email conversations was that there would seem to be great synergy between the #cidocCRM-based agenda of @ResearchSpace and that of SOCIAM, the well-funded and "well-endowed" team of researchers pursuing the "Social Machines" agenda (@project_sociam, http://www.SOCIAM.org). That synergy would not only be in terms of valuable cross-fertilization of the domains of study themselves, but for the #cidocCRM community, we gain "salable" vectors into funding sources. When we connect #cidocCRM as an executable metamodel for microservice systems that are Citizen Science, Citizen History, and Citizen Scholarship "Social Machines" I honestly think affective altruists' ears will perk up. I have to run... we have our first "Brewers, Brewpubs, and Beer Loving Friends of the DPLA" organizing meeting at our "home pub" @LionBridgeBrew in a half-hour. :D Happy-Healthy Vibes, -: Jim :- > -----Original Message----- > From: Crm-sig [mailto:[email protected]] On Behalf Of Dominic > Oldman > Sent: Sunday, May 17, 2015 10:22 AM > To: Sebastian Rahtz; martin > Cc: [email protected] > Subject: Re: [Crm-sig] Why #TEI P5 as format-of-record for #cidocCRM > Definition document > > > > It seems the right thing to do to spend some time on this to reduce FORTH's > costs here. > > That should be a core requirement. > > D > > ________________________________________ > From: Crm-sig [[email protected]] on behalf of Sebastian Rahtz > [[email protected]] > Sent: 17 May 2015 16:02 > To: martin > Cc: [email protected] > Subject: Re: [Crm-sig] Why #TEI P5 as format-of-record for #cidocCRM > Definition document > > Sorry, Martin, I was not meaning to criticize at all. I hope it didn't come over > like that. > > My reflections on this come from an interest in how software and similar > communities work; I have spent the last few decades hanging out in the > complex mini-worlds of TeX and of TEI, and its fascinating to see the > similarities between them and the CRM. > > ... > > Please do understand me right. We do all these services for free. None > > of this is because we would defend jobs or technology. Everything we do is a > big concern, not a slight one;-) . Everything better costs again. We need funding > for each migration:-( . > > > absolutely understood. I was not using proprietary in a critical sense. my > concern is that the future of the CRM is compromised if there are any > technology barriers to people working on it, and (for example) talking over the > maintenance if FORTH lose interest., > > ... > > The process, operations are complex and need control. XML is not a > database, it does not have functions. Of course you can put in in XML, and then > use an XML database on top to do the operations. > > It does not help you running IsA constraints on classes and properties, and > trigger sequences of changes. > > That needs code. > > it does. but I wouldn't distinguish so much between the XML representation of > the source and the XML representation of the functions. not the implementing > the functions doesnt need code itself, of course. > > I am thinking of the way an XML representation of a schema can embed all > sorts of rules and constraints in the form of Schematron. in another world, > you'll call that code, I call it part of the spec. > > > >> forgive me, but this looks like a tail wagging a dog :-} > > Well, forgive me also, what is the dog: The application S/W or the data > structure ;-) ? > > If the search and update operations are simple, a data structure may be the > dog. > > Otherwise....;-) > > true :-} > > > If anybody is seriously interested, we can send the complete requirements > analysis. > > Then we can make together checklists what the benefits are. > can you expand? the requirements analysis for what? > > > ... > > If we may go out of this business some day, nobody will be able to > > continue the process as it stands now. > > > precisely, that's what interests me. how you get to a setup which any > reasonably IT-literate person around the world can replicate, and take over the > CRM in the (highly unlikely!) event that a Grexit causes FORTH to go bankrupt. > > Sebastian Rahtz > Chief Data Architect > University of Oxford IT Services > +44 1865 283431 > > > > > > > _______________________________________________ > Crm-sig mailing list > [email protected] > http://lists.ics.forth.gr/mailman/listinfo/crm-sig > > _______________________________________________ > Crm-sig mailing list > [email protected] > http://lists.ics.forth.gr/mailman/listinfo/crm-sig
