The “Ride The Mainstream!” project for the IDESG, in 5 15 minutes

1. The “Ride The Mainstream!” project for the IDESG, in 515 minutes

2. Some immediate NSTIC and IDESG Standards Coordination implications • Provision for Anonymity/Pseudonymitybylimiting processing to specified context, implicitly implementing the principle of least privilege. • Criterion for success of proposed mini-projectwould be the desk-demonstrable ability to act as middleware between any combination of interoperating applications using n APIs, protocols or standards, with programming effort of the order of n, not n2 or higher. • Instructive impactson Taxonomy, Attributes, Use Cases, Functional Model, and Privacy Activities.

3. Reminder: The RTM project’s 2 main deliverables • TMA – The Mainstream Architecture for Common Knowledge, a new software engineering component architecture. It is surprisingly novel, and not only because it stands on a very wide and firm ontological and epistemological basis. (Don’t worry: that foundation is just a plain science of “the phenomenon of knowledge”!) • the AOS – Application Operating System, the program product and new universal front-end for all applications (though still a work-in-progress)

4. Some of the broader benefits of TMA-organized app development • Really RAD, with mostly market-prompted snap-in application composition, with quality • Access Control a natural part of app design • Transparent database and transaction design and management • Secure execution under the control of the AOS • Ontological basis enabling quantum leap in application evolvability in a market context

5. The first step proposed for the IDESG(at the end of the 5 min presentation) • SCC immediately involves existing Providers in the TMA-organized specification (that is, using ontologies in a TMA way) of current public interfaces and the modeling of Use Cases. Deliverables would enable initial AOS to rapidly verify old and help suggest new functionality. • Some big questions were posed, for example: • How does that offer anonymity? • Coding before design?! • How does this relate to Standards Coordination? • What would be the criteria for success?

6. TMA and the AOS helping peoplesimplify complexity together • Patterns for success in conceptualization, and anti-patterns for failure (That’s the wisdom of “The Homeric Mainstream”! Of the Logos too.) • Homer in The Odyssey: the cardinal sin is what I here call the “Fixed Ontology Fallacy” • Ontologies give us Being and Becoming, that is, constancy and change. Here’s how: • In a TMA-organized world, every processing step or transaction is a transformation of current data from being seen as instances of one ontology to being seen as instances of another.

7. On conceptual transformations(as mediated by TMA-organized ontologies) • Extremely variable granularity, usually nested. • But the AOS will always ensure correctness of processing following from the coherence and consistency of the respective ontologies, and the latter is (comparatively) easy to establish. • As a rule, efficiency of processing follows from the “bounded rationality” that usually pertains in the real human world (despite the nth order logic) • Orthogonal dimensions always help ensure that much-sought “separation of concerns”. • Context-switching as general form of creativity

8. 1. How does TMA offer anonymity? Anonymity (and pseudonymity) are merely one of the many possible consequences of Bounded Rationality Wikipedia: “Bounded rationality is the idea that in decision-making, rationality of individuals is limited by the information they have, the cognitive limitations of their minds, and the finite amount of time they have to make a decision. It was proposed by Herbert A. Simon as an alternative basis for the mathematical modeling of decision making, as used in economicsand related disciplines; it complements rationality as optimization, which views decision-making as a fully rational process of finding an optimal choice given the information available.

9. Bounded Rationality Is merely one of the phenomena of the natural Simplification of Complexity But whereas in microeconomics it is regarded as a human shortcoming and modeling problem, in TMA it is a feature we can leverage: if we can limit processing to specified context (and the AOS does so) we can offer anonymity and, more generally, actually effect the realization of the Principle of Least Privilege.

10. The Principle of Least Privilege From Wikipedia: • In practice, true least privilege is neither definable nor possible to enforce. Currently, there is no method that allows evaluation of a process to define the least amount of privileges it will need to perform its function. This is because it is not possible to know all the values of variables it may process, addresses it will need, or the precise time such things will be required. Currently, the closest practical approach is to eliminate privileges that can be manually evaluated as unnecessary. The resulting set of privileges still exceeds the true minimum required privileges for the process. • Another limitation is the granularity of control that the operating environment has over privileges for an individual process.[5] In practice, it is rarely possible to control a process's access to memory, processing time, I/O device addresses or modes with the precision needed to facilitate only the precise set of privileges a process will require. TMA enables an almost complete transcending of those limitations.

11. More on the first step proposed for the IDESG(The first task of an “Ontology AHG”?) • TMA & AOS workshop to know the TMA kind of ontology • Obtain several Providers’ interface specs, if possible for interoperation or federation. Dig for “full” semantics. • In the TMA way, model their data requirements, with present taxonomies, with appropriate levels of abstraction in the terms, determining commonalities and differences. Relevant ontologies will emerge. Improved Taxonomy too! • Check consistency between the assumed standards • Relate to use cases, determining functional model, down to a detail level, with state transitions. (Some blurring of important distinctions there!) • Address gaps with questions and suggestions (2 weeks’ full-time work for a small team?)

12. 2. Coding before design?! The weak answer: Remember that 2 steps were proposed: “SCC immediately involves existing Providers in the TMA-organized specification of current public interfaces and the modeling of Use Cases. Deliverables would enable initial AOS to rapidly verify old and help build new functionality.” Only the “help build” (or “suggest”) part would be new coding.

13. Yes, coding can often precede design That is a consequence of numerous major aspects or considerations. Here’s a mere sample: • Ontologies as components with highly orthogonal dimensions so more easily composed together. • High reuse of generic and even quite specific functionality, often automatically prompted by the AOS-driven component market. • The way cross-cutting concerns are provided for, in contrast with conventional API calls or OO methods. So we get high agility and thence evolvability, implying more effective discovery of needs.

14. 3. How does this relate to Standards Coordination? The immediate project proposed would be a demonstration of several important issues: • The AOS as a generic event-driven agent • The AOS as middleware, mediating interoperation • The tuning of interoperation using levels of abstraction, the ubiquitous but key feature. • In general it’s all about interface standards, including the support of multiple legacy kinds • Ability to support protocols as well as formats

15. 4. What would be the criteria for success? For the initial project as proposed (that is, before the first running AOS): The desk-demonstrable ability to act as middleware between any combination of interoperating applications using n interfacing standards, with programming effort of the order of n not n2 or higher. That would be thanks to the role of Common Knowledge expressed in terms of discovered TMA-organized ontologies. The AOS itself will strongly support that discovery process.