Introducing GRANITENET and the FELDSPAR Platform Agnostic Object System.

As the author of this article being someone who has developed a distinct sense of interest about the logic and the existing body of work in regards to concepts of operating systems design -- moreover, a sense of interest as with regards to the effects of specific design choices in operating systems design, as of design choices ultimately resulting in discrete effects with regards to operating system applications, in any single common domain of computing, including software development, and effects in regards to application system maintenance --  the author of this article, though for some time familiar with the Debian GNU/Linux operating system, the author of this article has lately become more a fan of the FreeBSD operating system. It is this author's candid opinion that FreeBSD presents a markedly less cluttered development environment than the GNU environment of GNU/Linux systems. Not as though to meanly criticize either the Free Software Foundation (FSF) or its supporters, the author of this article is aware that operating system distributions such as Debian GNU/Linux are systems that have evolved, over time, initially from relatively small-scale origins. Considering a conceptual paradigm in which GNU tools are developed as to be modular, moreover portable with other GNU tools, moreover in which the Linux kernel itself and applications of the Linux kernel have been shaped with developments in operating system standardization -- broadly, under a heading of a colloquial definition of UNIX systems, more specifically as under the headings of international standards such as the versions  of POSIX and specifications published by the Open Group and later X/Open company, moreover as with regards to standards published by the Internet Engineering Task Force (IETF) -- the author of this article is aware that it may entail no manner of a trivial work, to develop any single, working computer system out of so many individual software components and software systems standards.  Perhaps there has been a certain degree of centrally managed organization, in the development of the FreeBSD operating system -- if not, moreover, a greater degree of flexibility as with regards to distinctions of the BSD licenses, juxtaposed to the GNU Public License (GPL) or derivatives of the GPL -- such that may result in an impression -- as to the author's opinion -- that FreeBSD is a really well organized, really uncluttered operating system, moreover very easy to apply in begining software and systems development. Certainly, such an impression is aided with the availability of so many centrally managed reference documents about FreeBSD, as in regards to the FreeBSD base system and the FreeBSD kernel.

The author would not wish to abridge any introduction about FreeBSD. This article, presently, is developed not insomuch as to make an in depth study of the FreeBSD operating system, but rather to begin to develop a set of concepts that the author has found occurring to the author's own sense of consideration, during applications of the FreeBSD operating system. The author has been operating a local area network (LAN) with FreeBSD on the the LAN gateway host, on the software build host, and on the author's primary notebook laptop, on the LAN, for a small number of months. The author has begun to develop a concrete concept of the configuration of the same LAN, referring to it then as GraniteLAN. In an architectural sense, GraniteLAN may be integrated moreover with hosts configured of software defined networking (SDN) services -- there under the heading GraniteSDN -- as to develop an overall systems development network -- with the full network under the heading, GRANITENET. Presently, the author does not wish to develop any length sidebar about the architecture of the GRANITENET design, or the design philosophy of the same. It's basically a concept for a scalable DevOps network, and a small office/home office (SOHO) network, such that may be utilized not only from GRAITELAN, but moreover that may be utilized from a mobile appliance not immediately connected to but configured for connection to GRANITESDN. In its architecture, GRANITENET would apply a distinct number of common UNIX networking services, such as LDAP, NFS, NIS, Kerberos, and -- furthermore -- RADIUS.  Though it may seem relatively easy to write about, as such, but -- in order to develop a manageable framework of so many network services, as such, and for it to be relevant in regards to applications on contemporary operating system architectures -- it may not ultimately be as easy to "Glue together," in application of so many software components. At least, it may be easy to "Put together" the concept of GRANITENET's design -- initially, as it representing a manner of a paper machine, as to apply an older phrase to the  matter -- as it entailing a design of an effectively multi-homed application of the FreeBSD operating system.

In regards to the manageability of the design and applications of GRANITENET, of course there must be a manner of a design incentive thought to exist. The author might not believe that every reader would share the author's sense of appreciation about the logical design of each of Common Lisp the Language, 2nd Edition, and CORBA systems, furthermore the Object Management Group's concepts of Object Management Architecture and Model Driven Architecture -- moreover, the portability of systems developed onto CORBA and, separately, the portability of applications developed onto the Common Language Infrastruture (CLI), the latter as popularized of the Microsoft Dot-NET and the Xamarin and Mono platforms, furthermore as standardized onto ECMA-335.

Insofar as it representing a concept of a paper machine,  the author has certainly expended some paper and graphite, in putting together a number of offline notes about the design of GRANITENET, moreover the design of a system the author denotes as FELDSPAR. FELDSPAR would represent an application of Common Lisp, CORBA, and the Common Lisp Interface Manager, as to create a bundled application development kit of free/open source software for applications of the same software and systems components. In that regards, perhaps it might seem like overmuch of an aspiring goal -- as to apply GRANITENET in developing the FELDSPAR framework, while GRANITENET is not even completely constructed, in itself, as yet. However, in retaining a sense of focus about the logical qualities of the design of each of GRANITENET and the FELDSPAR framework, it therefore remains a manageable set of concepts, at least to the author's own sense of consideration.

In beginning to describe these discrete concepts to the Internet audience, it must naturally entail a development of a literal body of documentation. Thus -- in focusing about the Darwin Information Typing Architecture (DITA) -- there is a sense of a topic repository model developed in the FELDSPAR systems design, insofar as of the present paper machine edition of the FELDSPAR systems design. The topic repository model -- in some regards, semantically -- it might resemble something of a concept like of a Wiki. Though a FELDSPAR topic repository would be published to the Web, but -- in it utilizing DITA,l in its content source model -- it would not be immediately managed "on the web". The FELDSPAR Topic Repository model would allow for managing the body of content of a topic repository, as in application of so many DITA editing tools, multimedia content development tools, and changeset management tool such as Git -- without HTTP interverning between the editor and the filesystem. As such, perhaps it may not seem to be an immediately enterprise friendly framework, but perhaps it may be scalable outwards from its initial SOHO friendly design.

In beginning to document this design, in a digital format of text, the author of this article wishes to make reference -- immediately -- reference to MARTE, specifically MARTE 1.1, furthermore to make reference to the DOAP RDF schema. Surely, it may be possible to develop a great amount of semantic sugar, in application of such normative specifications. Presently, the author wishes to recommend a concept of software platform, in an abstract sense, as may be extended to subsume concepts both of operating system platform and of toolchain architecture, furthermore as to provide a sense of structure about application components commonly referred to as libraries -- then to include the DOAP RDF schema, as to develop a documentation framework with which software developers may be able to make consistent, ostensibly convenient reference to all points of upstream software distribution, for any single software component.

Towards developing an initial usage case to this sense of structure in software and systems: The author of this article has begun to write a small series of notes, in the author's own Evernote notebook, as to begin to develop some normative documentation towards an application of the Enlightenment Foundation Libraries (EFL) and the EFL WebKit integration, namely towards developing an EFL port for the Common Lisp Interface Manager (CLIM) as well as extensions for CLIM, in regards to web appliations, such that would be developed as for application at least onto FreeBSD, Linux Desktop, Android Mobile, and Microsoft Windows Desktop operating system platforms.  Perhaps it aspires as towards a comprehensive design, to be thorough in regards to development and support of operating system applications.

Though the author is furthermore interested about some concepts of microcontroller design, reprogrammable computing, and the history of the infamous Lisp Machine, but perhaps it may turn out to be a manner of a fortuitous effort, to begin with regards to applications of existing microprocessor achitectures and existing operating systems, specifically beginning at the manner of a colloquial UNIX-like framework developed of the FreeBSD Project -- furthermore, as FreeBSD being extended in a small number of by-in-large domain-special FreeBSD distributions.

So, that would be towards an unabridged introduction.

In focusing immediately towards applications of the EFL toolkit, there is immediately a concern that occurs as with regards to illustrating the toolkit's software components and software component depencencies, as towards any single distribution of the EFL toolkit -- in a sense, as towards any single distribution of a bundled set of EFL toolkit components, whether immediately with or without the EFL WebKit integration, and finally in a distribution to any single operating system platform, in application of any single toolchain architecture. This would be essentially orthogonal to -- but, in a sense, essential to -- the development of a CLIM port for EFL.

The author proposes to develop a model for each of the following concepts, in extending the MARTE 1.1 Profile for the UML metamodel:

• Concrete Computer Machine Architecture --  immediately, perhaps extending of the Detailed Resource Model defined in MARTE 1.1
• e.g. as in reference to:
• The FreeBSD sysctl property, `hw.model`
• Compiler optimizations as may be specified in FreeBSD /etc/make.conf and/or FreeBSD /etc/src.conf
• Machine architectures in Debian GNU/Linux
• Machine architectures in the GNU Compiler Collection
• Abstract Software Platform -- likewise, perhaps extending of the Detailed Resource Model defined in MARTE 1.1
• Concrete Operating System Platform
• Concrette Toolchain arhitecture
• e.g. MINGW 
• Subsumes: MINGW x86-64
• Abstract Software Application and correspondingly, Abstract Software Distribution, in a noun sense of the latter term
• Software Distribution/Application model on a FreeBSD operating system
• Software Distribution/Application on a Linux operating system
• Software Distribution/Application on a Debian or Ubuntu GNU/Linux operating system
• Software Distribution/Application on an Android Operating System
• Software Distribution/Application on a Microsoft Windows operating system

Orthogonally, it is the author's hope that the resulting UML profile models will be compatible onto the CORBA Component Model -- such that, in a sense, may complemented with a UML profile model extending of the concept of abstract software application, if not moreover integrating a manner of a system for software distribution in regards to CORBA components, there certainly making reference to OSGi and also Maven.

That being so, then how may the author propose to publish a UML profile model, in any vendor-compatible regards? The author proposes to apply Modelio, and to publish the UML profile models finally as serialized XMI. The author furthermore proposes to apply the respective UML profile models, in development of a manner of a component metadata database, there integrating the DOAP RDF schema and some manner of a web publishing model for presenting the metadata database, in any managed manner, online. The DOAP RDF integration, in itself, may entail a development of an extensional RDF schema, moreover an application of some existing tools for RDF graph modeling in Common Lisp.

Of course, there is a sort of a boostrapping dilemma, in such design. The author proposes to address the bootstrapping dilemma, in -- albeit, perhaps in something of a expressly nolinear sense -- but in an overall iterative sense, however. In such a sense, the author does not propose to specify that the design of the RDF application would wait on the design of the project-oriented management information system (Project MIS). The RDF application must wait, however, for the design of the final component metadata schema.

Towards such an application of RDF, the author wishes to comment towards a sense of applying Common Lisp as a data system feature, within a data programming system, there closely and comprehensively integratred with the underlying operating system. The author proposes to limit this specific design to the FreeBSD operating system,  moreover to focus about a small number of individual, concrete components such as already developed as and for individual Common Lisp implementations. The goal of this aspect of the design, to the author's opinion, the goal is to support software systems development with software systems development and documentation. In such a regards, perhaps it might seem like a manner of a DevOps concept, however developed of a popularly unconventional framework

The RDF application, specifically, it may be developed as to extend of an XML Schema Datatypes implementation. As in a manner across the XML Schema Datatypes Implementation, it may be integrated onto a data persistence model for RDF, there to apply a HypersonicSQL service as a data storage service.

If there may be a rhetorical question, such as, "Where to begin, next?" the author prpoposes to continue with the development of the UML profile models, as denoted herein.

A Review of CLIM Presentation Types (Draft 5)

The Common Lisp Interface Manager specification, version 2 (CLIM 2) defines an architecture for an implementation-generic type system -- essentially. a type system orthogonal to the underlying Common Lisp Object System (CLOS) -- as namely, in the presentation types architecture defined in CLIM 2.

There might be a question that may occur, as in an inquisitively rhetorical manner, as to why the CLIM 2 presentation types system is defined in a manner essentially orthogonal CLOS, moreover independent of CLOS? One might speculate: At the time when CLIM 2 was developed as a specification, moreover at that time in the evolution of the Common Lisp software programming language, perhaps CLOS may not then have been regarded a it being a mature object system, sufficient for CLOS to be more thoroughly, if not singularly adopted for application in CLIM? Considering the development of the Metaobject Protocol (MOP) for CLOS implementation, in a sense of historic tiimelines, perhaps the development of the MOP specification and its subsequent publication -- that, as in The Art of the Metaobject Protocol (AMOP), also in the MOP implementation codified as PCL -- perhaps that may have served to lend more of a sense of codebase maturity for adoption of the CLOS specification.

Alternately, considering the syntax of CLIM 2 presentation type identities, perhaps a singularly CLOS-oriented architecture might not seem sufficient, without it being integrated with any number of implementation-specific details, as to the  nature of the implementation of the fundamental type system in any single Common Lisp implementation.

Inasmuch as CLIM may be furthermore adapted, if not centrally revised for alignment with CLOS and MOP, but of course such adaptations should be accompanied with some substantial documentation, as towards existing forms and adapted forms, and rationale, etc.

Reviewing a small number of albeit superficial qualities of the design of the CLIM presentation types system, one may arrive at any small number of observations. Towards developing an abstract model of CLIM, this article will make note of the following observations:

• CLIM 2 specifies behaviors for definitions of presentation type, presentation generic functions, and presentation methods
• The type identity of a presentation type may be specified with a syntax analogous to the syntax of conventional Common Lisp type specifiers.
• An orthogonal observation: Some implementation-specific features may be developed in an implementation of CLIM, such that for dispatching in selection of any one or more CLIM type specifiers, for any single value, a manner of "Presentation type matching algorithm" may be developed in extending directly of an implementation's underlying type system, as towards a concept of implementation-specific optimization in implementations of CLIM
• Prospectively, as may be correlated to the previous observation, a CLOS method specializer type may be developed -- albeit, in an implementation-specific manner -- for purpose of specializing CLOS methods onto ordinary Common Lisp type specifiers. Such a formal definition may be accompanied with a thorough description of  how the matching algorithm would be applied, in the implementation, for any single range of Common Lisp union, intersection, numeric, sequence, or other type specifiers. Towards a practical observation, perhaps it may be be a relatively straightforward endeavor, to develop such an extension onto CMU Common Lisp (CMUCL), or the highly specialized fork of CMUCL, Steel Bank Common Lisp (SBCL) -- that, as in referencing the ctypes architecture defined in CMUCL, furthermore inherited by SBCL. 
• The conventional `define-presentation-type` macro defined in CLIM 2 allows for definition of a presentation type with a quality of multiple inheritance -- albeit, as would be constrained to the set of presentation types defined in any single application of CLIM2. 
• In searching for an analogy to CLOS, perhaps it might be thought as that the inherits-from property might be viewed as it being analogous to the class-direct-superclasses accessor defined in MOP,  In a broad sense, it may be similar. 
• The CLIM 2 specification does not define any analogous processing for the inherits-from property, in any ways exactly analogous to class-direct-superclasses or the computation of a CLOS class' class precedence list.
• Considering the CLIM 2 presentation types system as a type system, effectively the CLIM 2 presentation types system provides a sort of presentational/interactive layer onto the entire Common Lisp Object System. As such, it might be understood if the CLIM 2 specification does not delve into so many implementation-specific conventions as might be required for defining any manner of inheritance among non-class data types -- e.g. does a hypothetical '(int 32)' extend of a hypothetical '(int 16)', in a "Subclass has a wider field" sense? or vice versa? or not at all? The semantics of such inheritance would be orthogonal to the functional characteristics of any manner of machine-local memory registers.
• Moreover, CLIM 2 does not appear to define any manner of an accessor for the property's value, for any single object or class as may represent a presentation type definition -- that is, to suggest that the information of the presentation type inherits-from property is effectively lost to any portable, implementation-generic forms, when define-presentation-type  is evaluated. That, in itself, could be revised with an implementation-specific adaptation of CLIM such as to store a value evaluated of the  inherits-from property and to provide that value for applications. Such divergences from CLIM2  should likewise be documented as such.
• The CLIM 2 specification defines a presentation type history property for presentation type definitions made with define-presentation-type. 
• This might seem to introduce something of an orthogonal, application-layer property to the fundamental presentation types system in CLIM.  
• In a functional sense, a presentation types history property may be applied within an application, as in regards to input recording for values input via a presentation type's accept method(s). 
• Although perhaps that may seem convenient for development of a CLIM application in any single-application Lisp process, but perhaps this property may be reconsidered as towards a small number of contexts:
• Multiuser computing environments -- if a CLIM application may be applied in a multi-user Common Lisp process, such that the Common Lisp process may serve multiple users simultaneously -- may therefore contain, at any one time, user data from multiple users
• Multiple applications in one process -- as for any single Common Lisp process providing multiple CLIM applications to a single user,
• In either of those instances, the generic presentation type history -- as a property defined of any single presentation type -- might be discarded by the implementation, in lieu of an application-specific and user-specific input recording functionality.
• This, of course, may serve to call a concern towards the broader input recording  mechanisms of CLIM, concerning privacy of user data in any potential applications of CLIM in any Lisp process providing a multi-user or multi-application environment 
• Considering, the parameters-are-types property -- as permitted in applications of define-presentation-type -- perhaps the nature of that property might seem a bit confusing, in some regards -- as to its processing for presentation type definitions made with define-presentation-type.  A small number of questions:
• What specific parameters does the property make reference to, as in  an evaluation of any single define-presentation-type form?
• Is there an example available, if not a single case study as for when those same parameters, in any instance, would not be presentation types?
• Looking ahead to when this article might address qualities of presentation functions and presentation methods, then considering a CLOS-based implementation of each, how would properties of CLOS method dispatching -- inasmuch as in a standard method dispatching, and other method dispatching forms specified in AMOP -- how would may any single manner of method dispatching affect the behaviors of a CLIM presentation method, in applications?

Certainly, the design of CLIM presentation types may permit much more of detailed review, as to further juxtapose CLIM presentation generic functions and presentation methods onto CLOS. 

Perhaps, furthermore, an extensional method dispatching framework may be developed for optimal method dispatching onto presentation methods. 

Presently, the author shall endeavor to review the author's own notes, to this point, in this article of discourse.

• Draft 1: Initial document
• Draft 2: Concerning the inherits-from property for define-presentation-type, making some little more of clarification as towards a juxtaposition onto CLOS
• Draft 3: Adding a note towards an analysis of conventions for method dispatching and, orthogonally, application behaviors in a CLOS/MOP implementation of CLIM presentation methods
• Draft 4: Once again beginning a thesis with regards to UML, SysML, and CLtL2, and CLIM
• Draft 5: Adding "A short listing of I/O forms in CLIM"

Appendix: A short listing of I/O forms in CLIM, indexed by feature

• gestures: stream-read-gesture, stream-unread-gesture
• presentation types: accept / present [Function] -- correspondingly, ... / stream-present, furthermore present-to-string, presentation-replace-input
• commands: read-command
• tokens: read-token / write-token
• strings (input substring replacement): replace-input
• presentation types (input replacement): presentation-replace-input

Appendix: Facilitating discussions of API design decisions, using UML and SysML

Although perhaps it may not represent the most popular of a topic for contemporary discussion, but considering it as a feature of the body of existing work in domains of computing and documentation, the Object Management Group (OMG) specifications for the Metaobject Framework (MOF) and correspondingly, the Unified Modeling Language (UML) and Systems Modeling Language (SysML) metamodels, in each, may be applied for some purposes in illustrating the compositions and behaviors of system elements, as in a system such as of the CLIM 2 specification itself, and in regards to any single implementation of CLIM 2.

Although it may require a substantial design effort -- perhaps, to no clearly popular results moreover -- a metamodel may be defined specifically for modeling of Common Lisp, the Language, 2nd edition (CLtL2) in UML and/or SysML. In a hypothetical extension of such a hypothetical metamodel, a model library may then be developed for describing CLIM2 itself -- in a manner extending of an original mettamodel for CLtL2 -- and a corresponding model library for describing any single implementation of CLIM2.

Alternate to developing a complete metamodel for CLtL2, an approach may be developed for producing an initial UML Profile for CLtL2, such that may extend of the UML and/or SysML metamodels. This approach -- though, to an estimate,, it may seem perhaps more tedious than the direct metamodel approach -- it may serve to allow for that a model developed in an application of the UML Profile could then be applied in any number of existing modeling tools -- such as for generation and analysis of software source forms -- such that any single modeling tool may provide any manner of support for applications of models applying either or both of the UML and/or SysML metaodels.

Not as though the UML Profile approach could not be in any ways tedious in itself, even so much as a simple list structured data type in Common Lisp may require a substantial diagram as to illustrate its complete syntax and possible syntactic variants, in UML. To that effect, the author wishes to make note to albeit an offhand study of some list-structured syntactic forms defined in ASDF,

As one possible benefit of such a work in systems modeling, it may then be relatively easier to present any of a component-oriented view of the behaviors of a CLIM 2 system, in a manner independent of Common Lisp syntax, in applying the resulting UML model library commensurate with documentation. In even more of a hypothetical "Long shot," proverbially: Such an effort in turn, could serve to facilitate a development of a CORBA application model for CLIM2, such that -- lastly -- could be applied in developing an interface onto any single graphical toolkit, in any of the body of existing work in desktop computer interface design, and moreover that could be applied in mobile computing platforms, without any of a specifically platform-centric API.

Of course -- continuing with the ad hoc metaphor -- that would be a long ways to go, to develop a SysML view of CLIM2. Clearly, the popular market may seem to favor much more of any number of immediately stylish applications. Common Lisp not being particularly stylish or immediate, it simply may not "Fit" with "The Modern Market."

Onto ... Graph Theory in Applications of Ontology

Though with apology to the indeterminate readership, I don't have a convenient bibliography to present about it, offhand, personally I've been studying some concepts in ontology, for a small number of years -- all, in informal study. I've really not ever managed to develop an academic transcript adequate for transfer to any manner of an Ivy League school or anything like. I suppose, personally I'm still trying to understand what academia means, to me, as academia being such that I consider to be a necessary part of life. I would not wish to make any long sort of an anecdote as to denote why I consider that I'm of such a view, perhaps it's a bit of a meta-semantic sidebar anyway, towards the present article.

Presently, I've begun to develop a thesis concept with regards to how ontologies may be applied in a sense of personal or academic knowledge management -- nothing quite so technically aspiring as the Nepomuk ontologies, though I suppose it could "Aim" towards that, at some time, as when there would be any applications to speak of that could utilize Nepomuk's facilities for adding an ontological layer onto personal information management (PIM). Presently, I'm trying to focus more about a concept of concept -- in a manner of a literary sense of concept -- such as may presented meta-semantically in extensions of the SKOS ontology.

Considering an ontology, in a generic sense, as a form of a reference medium, orthogonally, one may endeavor to view an ontology as it being essentially a literary kind of reference medium. However an ontology -- whether in RDF, OWL as extending of RDF, KIF, Common Logic, or other format -- however stored or transmitted in its essential structures, an ontology typically contains a lot of essentially textual information. In a sense of RDF, an ontology may contain textual information in forms of short texts about resources -- texts that are likewise resources, such that may be furthermore reified as resources, within any single RDF graph medium. Perhaps it may ever be recognized as a nice susbset of application media, the set of ontological graphs altogether.

Presently, I would like to denote a simple thesis statement that I've been able to etch out the raw stuff of own knowledge, this evening: In a practical application of ontologies, focusing namely on the Web Ontology Language (OWL), one may define two categories of OWL ontology for practical applications:

• Structural Ontologies, containing definitions of OWL Class, Object Property, Datatype Property, XSD Datatypes, and Annotation Properties for applications
• Instance Ontologies, as applications of structural ontologies, such that would be applied in definition of OWL Indvidual type resources, in extending of structural ontologies.

Though I would not wish to seem excessively proprietary about it, personally I've begun to develop a corresponding thesis about a small set of structural ontologies, such that may be applied in tracing of information conveyed in jouranilsm, and might likewise be of some use for applications perhaps in at least an ad hoc manner of field archaeology. In a trivial sense, it may be decandted to a matter of: Persons, Places, Events and References, in a bibliographical sense. The Events concept might seem to be the pivotal concept, at that -- in however an event may be in any sense singularly defined, as in a  context of any single literary work.

There's a fifth concept that I would like to add to that small list, this evening, if one may endeavor to develop at least an ad hoc sense of structural geneaology. It's a concept that I've yet to find any single ontology for, however -- essentially, orthogonal to an Events ontology, if there may be any single ontology for literary endeavors about constructed objects. I do know of a small few of resources I could revisit online, as to do conduct more research about that concept, perhaps this evening. I'm afraid that it might be a bit of a disorganized list, if I'd try to itemize that set of resources, immediately. It's also a task wholly orthogonal to the thesis topic that I'd hoped I might be able to begin to write down, presently -- and although the latter may be a bit of a vague idea anyway, but it's such that I'd like to continue to whittle about, literally, towards further developing an idea for application of a small set of structural ontologies and instance ontologies in ... in no exacting usage case, as yet.

Personally, I'm not certain of how far a concept of proprietary knowledge may or may not extend into formal academia. Towards my further sense of disdain at that sense of ambiguity, even if I am researching of these topics, informally -- not being a student of any single, formal course about ontology, at present -- I consider that I should certainly try to respect any number of formal academic models, even in my own research and writing -- at least inasmuch as I  might understand such models, candidly.

What, then, do I mean by proprietary knowledge?  In as much of an exacting sense as in which I can try to define what I mean, in that phrase: I mean, any knowledge legally and necessarily protected under terms like with regards to literal intellectual property. Not as if to indulge in writing any lengthy sidebar with regards to any sense of  commercial intelligences or small business, but if I would denote intelligence as a noun, I consider that I should as well denote how it is a noun that I consider has a natural, plural form. At that, though, I think it goes far towards psychology, and personally I'm not well read about that domain of academia.  It would be quite a sidebar to begin, this evening, to define what I may mean to denote by that simple term, in an exacting sense.

So, but in being aware of some concepts of proprietary knowledge, and in avoiding any particularly revolutionarily characteristic sort of views about any concepts of propriety, I know there are things that I know, such that -- for online discourse, and not only -- that I advise myself, implicitly, to not even denote I know. Perhaps it's a bit of an odd thing, but "That's life," as I understand it -- never 110% transparent. I feel that that's such that I should denote, distinctly, before any further discussion of ontologies. Orthogonal to that oblique disclaimer, I know there are things that I don't know, too -- if there may ever be any single count of known things, probably more things in the second category than in the "Immediate knowledge" category. I think it's as well to not be too deterministic about knowledge -- moreover that science, as a human effort, indicates that no person's knowledge is ever absolute and complete.

Perhaps its simply that I wanted to note, this evening, that there is a thesis concept, vaguely "Here," and that I know there's probably more of a bibliography about it, mroe than what I have ever found, as such. Perhaps, either, I'm simply trying to circumscribe an arc around a notable gap with regards to any profound and immediate illustration of a thesis concept, in software, such as may entail an application of any number of concepts in ontology.

In my not being direct, in this article, I'm certainly not trying to avoid mentioning any manner of a pink elephant in the room, with regards to applications of ontologies. Orthogonally, I don't personally happen to follow the logic of the Manning/Snowden/Assange conspiracy, though I have certainly read of it. 

Inasmuch as considering that a study of academia may entail, implicitly, a study of a veritable plethora of knowledge, namely human knowledge --inasmuch as even to present the ultimate, existentially challenging question, What is knowledge? -- perhaps, though, what I should be concerned about with a perspective about software, perhaps it  may be more towards a practical question of presentation, How well may knowledge be presented?

Not to cut corners in this informal thesis, I understand that there's a design as for a human-computer interface (HCI) toolkit, the Common Lisp Interface Manager (CLIM). As an HCI toolkit, perhaps the design of CLIM, so far as to CLIM 2, has been focused about graphical displays and keyboard interactions, but certainly that's in keeping with the sort of HCI environment that we may be most familiar with, as sighted computer users at personal computers.

CLIM presents something of a simple, basic, practical model for HCI implementation in graphical display/textual keyboard/on-screen pointer environments. Also, CLIM has some features catered for print-based representation of graphical objects, as towards a sense of print as media.

Personally, candidly,, perhaps I have not always been a great fan of the interface for the CLIM obect model, in Common Lisp. I'm a little put off that it doesn't seem, to me, that it completely utilizes the Metaobject Protocol (MOP), though I know MOP is not an ANSI-standard fare in the Common Lisp Object System (CLOS) anyway. I simply think there must be a more effective way to program interfaces with CLIM, of maybe that's simply too naive of an idea.

As it being an object model however, I'd say CLIM is pretty square.

So, now I'll just jump right to the point of applying CLIM and Franz Allegrograph -- taking a short break from this thesis article, presently

Franz, Inc. publishes a VMDK edition of their semantic information systems platform, AllegroGraph. Presently, the VMDK edition includes AllegroGraph pre-installed in a 64-bit Ubuntu 14.04 OS, the Trusty Tarpaulin edition of the Debian-based Ubuntu GNU/Linux operating system. The VMDK can be installed to a virtual appliance in VirtualBox, or any number of other desktop-based virtualization systems. In a nutshell, it provides a quick start-and-go interface for working with Franz AllegroGraph.

As far as how to configure VirtualBox networking for accessing the VMDK from outside of the VMDK's software space ... that will not be presented with details, in this article. The VirtualBox manual includes the complete details of that. This article will assume that the VirtualBox virtual guest appliance is configured with VirtualBox NAT networking, with a host interface having the IP address 172.16.42.1

Moreover, this article assumes AllegoGraph is configured in agraph.cfg, with at least the following configuration directives:

Hostname 10.0.2.15
Port 10035

Thirdly, this article will assume that the VirtualBox NAT networking is configured for port forwarding in the VirtualBox interface between the virutal host OS and the virtual guest OS, simply to the effect:

172.16.42.1:10035 <=> 10.0.2.15:10035

With such a configuration installed, a developer may apply any of the AllegroGraph clients, in developing on the virutal host OS -- with apology, developing no lengthy side-thesis about software defined networking (SDN), here, or either, about integrated development environment (IDE) platforms applicable for Common Lisp software development. In a practical sense, certainly such configuration properties can be managed via software, but even in so much of automation, it probably would help to understand at least a little bit about TCP/IP networking. Within the virtual host OS, the networking and port forwarding properties can be managed via the VBoxManage shell command. Within the virutal guest OS, as in this example, the configuration properties can be managed via both of the files, /etc/network/interfaces and /home/franz/ag/lib/agraph.cfg

So, with such a configuration installed, there are the AllegroGraph clients, and a bit more of TCP/IP networking. Beyond a context of VirtualBox host-only networking, a framework for SSH port forwarding could be applied, on top of the VirtualBox port forwarding.

Presently, this thesis article will jump, by a certain distance, to develop some concepts about object models. The development of that aspect of this thesis article must naturally entail a presentation about some concepts developed in CLIM. This article will now assume an outline format, towards an overview about CLIM.

CLIM - An Overview

• Interaction
• Menus
• Key bindings
• Modeline
• Presentation
• Presentation types
• Presentation methods
• Device Interface
• CLIM port
• CLX port
• GTK Cairo port
• ...
• HCI structures in CLIM applications
• CLIM Graft and Sheet objects
• CLIM Frame objects
• The application frame class
• ...
• CLIM Pane objects
• The application pane class
• ...
• Objects displayed on a CLIM pane
• Geometric objects via CLIM drawing forms
• Text via CLIM drawing forms
• Presentations
• ...
• CLIM and Common Lisp
• Streams in CLIM
• ...
• CLIM and X.org
• XLib
• CLX
• Adding support for XFree86 shared memory extension 
• TBD
• Input methods
• Integration with window managers
• Integration with desktop environments
• ...
• CLIM and text media
• ...
• ...
• Climacs
• ...
• CLIM and CORBA
• TBD - Thesis not yet developed

Secondly, this article will now develop an outline focusing on Franz AllegroGraph as an RDF information service.

Towards developing a CLIM layer for AllegroGraph - Notes / Outline

• Presentation Types
• Triple Store / DB
• Triple
• subject, predicate, object
• graph
• triple ID
• Resource
• Unique Part Identifier (UPI) strings
• Class
• RDF Schema
• OWL
• Annotation properties
• rdfs:label
• skos:altLabel
• skos:prefLabel
• skos:hiddenLabel
• Graph Display
• Graph 'link' properties
• e.g. SKOS broader / narrower properties
• Graph layout
• Radial graph
• Hyperbolic graph
• Tree graph
• Resources may appear multiple times in a tree graph hierarchy
• Resource aliasing for individual presentation in tree graph
• Graph Management
• Graph Management Actions (Default)
• Open graph service connection (i.e. connect to graph server)
• Create graph DB
• Delete graph DB
• Rename (?) graph DB
• Close graph service connection (i.e. disconnect from graph server)
• Graph Management Panes
• List of "registered" graph DBs
• Registry by way of application of ... something compatible with CORBA object services (TBD) (Persistent naming, etc)
• TBD: Implementing an access control layer onto AllegroGraph triple stores
• Fundamental service interface model
• Implementation as an adapter
• Graph service: AllegroGraph
• Display management: CLIM
• Integration with CORBA
• TBD - more towards providing a triples-graph service for other graph/SPARQL servers in Common Lisp or Java
• Usage Cases
• TBD

Lastly, this article  will endeavor to develop a platform-agnostic view about RDF media and CLIM -- again, presented here in an outline format.

Broader Context: CLIM + Semantic Web (A Generic Model)

• RDF Resources // URI Referencing
• See also: ODM
• Generic  model for collections of RDF tuples
• Concept: tuples-index
• Registration of RDF namespace per triples-index
• Classification of ontologies
• Application: Per-ontology presentation method selection
• Examples // Use Cases
• Presentation methods for SKOS Concept classes
• Presentation methods for RTM Topic classes
• Selection criteria for classification in resource => presentation type assignment
• RDF namespace of resource's RDF URI
• Type of entity (RDS class, OWL class, RDF property, OWL object property, OWL datatype property, OWL annotation property, XSD type)
• Properties defined to entity
• Requires a full-graph search initially
• List of properties may be updated on graph change
• Concern: Concurrency
• RDFS/OWL Classes & CLIM Presentation Types
• RDFS/OWL classes available only in connection to any single tuples-index
• Presentation types may be defined as in association to an individual RDF namespace
• Presentation types may be defined as in association to an individual tuples-index
• Presentation types may be defined in individual source trees
• Such source trees may be referenced as in an index or transformation of the URI of any single ontology namespace (?)
• ? Internal table for registration of presentation types for reference via presentation methods
• Concept: Presentation of tuples
• Classic presentation mode: subject, predicate, object
• Presentation of each of a subject, predicate, object will be affected by presentation method defined for each individual resource referenced in that field of each tuple
• Concept: Presentation of reified tuples
• Append 'button' area for activating presentation layer for reification data
• Project: Object model for SPARQL
• CLIM layer
• Concept: Table view (onto SPARQL)
• per each column
• An RDF/OWL property
• Column displays resource denoted in that property
• A column heading
• per each table
• SPARQL query (as an object)
• "Key" column[s]
• applicable for sorting in table display
• Concept: Graph view (onto SPARQL)
• Concept: Metadata view (onto any single set of specifications/standards/conventions in a context of linked open data )
• Arbitrary
• Usage cases (blue sky?)
• Bibliographical display and editing [application]
• "FOAFpedia" app
• Integration platform (app) for collation of bibliographical information
• Bibliographical information for "Good Jedi"
• Is not LinkedIn
• Is not Encyclopedia Britannica, etc
• Bibliographical information for "Dark side of the moon"
• Is not INTERPOL's single registry or analogous national registries
• Topic maps
• Alternate to "Mind maps"
• Concerns
• Implementation in CLIM
• Integration with file media
• Integration with desktop/mobile computing systems
• Resource graph as a central data service on each platform
• Resource graphs on desktop platforms
• Nepomuk
• TBD
• Resource graphs on mobile platforms
• See also: androjena
• Resource graphs on enterprise server platforms
• (?)
• Service model
• Interface model
• Resource=>application dispatching on Android platform - i.e "Open with..."
• See also: 
• Java Content Repository (JCR) (2.0)
• JSR-283
• Implementations (Java)
• Modeshape
• Apache Jackrabbit
• DOM L3 Load & Save
• Towards a streams model for CORBA
• Integration with web media
• See also
• Vincent, Cristopher R. W3P: A Portable Presentation System for the World-Wide Web
• Presentation: Article
• Presentation: Slides
• HTTP Services - Common Lisp
• CL-HTTP at NTT-Data
• Hunchentoot
• Concept: HTTP as an application-layer service
• OSI seven layer model
• TCP sockets
• Trivial request/response cycle
• Response codes
• HTTP 1.1 - See also
• In Proceedings: The Eighth International  World Wide Web Conference (1999)
• Krishnamurthy et. al. Key Differences between HTTP/1.0 and HTTP/1.1   
• Kaplan and Oldham. Managing TCP Connections under Persistent HTTP
• HTTP proxying
• WebDAV
• Concept: HTTP as a CORBA object service
• Web resource as object
• Accessible via HTTP/HTTPS
• Identified with a request URI
• Related: Request method (GET, POST, etc)
• May require persistent state data for access
• Persistent client identity data (cookies)
• Writable via WebDAV
• CORBA
• ODM

Towards a set of concepts for a separate focus article:

• Prolific mobile computing
• Mobile operating systems utilizing the Linux kernel
• Android platform
• Manufacturer-specific applicaitons
• Firefox OS
• Apple iOS
• BlackBerry
• See also: QNX
• Prolific laptop computing
• Google Chromebook
• Also based on the Linux kernel
• Microsoft Windows laptops
• ...
• Ubuntu laptops
• HP TouchSmart laptops
• FreeBSD desktop distributions
• ????
• Computing in Small Office/Home Office (SOHO)  Environments
• Software Defined Networking (SDN) as scalable online service platform
• Amazon Web Services (AWS)
• OpenShift Origin
• Digital Ocean
• ...
• System on Chip (SoC) platforms and single-board computing platforms
• Texas Instruments AM35xx Sitara SoC
• BeagleBone Black
• Allwin A20 SoC
• Cubieboard 3 (Cubietruck)
• Broadcom BCM2835 SoC
• Raspberry Pi
• Alternate design concept: Computer on module (CoM)
• Juxtaposed to SoC as a design concept
• Commercially, another delivery platform for manufacturer's microcircuit designs
• e.g. Gumstix
• Company profile at Texas Instruments
• See also: Gumstix Gepetto

In a View of a Software Project as a Tree-Like Structure: Towards Memory Locking and Memory Access Control in Common Lisp Programs

On beginning a study of National Instruments' LabVIEW programming platform, last year -- that, as was contingent on being a student of a sort of vocationally-focused introductory program in computing, networking, and the electrical sciences, a program hosted by a certain online university -- the author if this article has begun studying a broader concept of data flow programming. Contingent with that study -- not as if try to trump-up any competition towards National Instruments (NI) but rather towards a broader academic study of data flow programming -- the author has been developing an expression of a concept of data flow programming, in Common Lisp.

The author would gladly make reference to the source-tree for that item, here, but it may not be in any useful state for applications, presently. The author has been referring to the project as eSym -- as to denote something towards a concept combining of component concept of symbolic logic and a metaphor with regards to electrical current flow.


While developing eSym, the author has discovered a number of complimentary concerns that may be addressed in a Common Lisp program. Those concerns may be addressed before eSym would be any further developed.

The following article presents an outline of those initial concerns, then proceeds to develop some concepts as with regards to a sense of a broader context in development software programs in Common Lisp.

• An extension may be defined onto the Common Lisp Object System (CLOS) -- at the least, in implementations applying of the Metaobject Protocol (MOP) -- such that the extension would allow for a thread-local modal locking procedure -- and more specifically, a read/write locking procedure -- onto slot values of a Common Lisp standard object.
• This, in turn, may be implemented onto a portable interface for modal locking, such that may be developed directly onto Bordeaux Threads (BT), in a platform-agnostic model
• In parallel to developing a modal locking layer onto Bordeaux Threads, an additional portability interface may be developed onto so many implementation-specific timer interfaces
• ....such that may then be applied in a revised `BT:WITH-LOCK` then allowing a blocking keyword argument -- the behaviors of which would be fully described in the documentation, but in summary of which: 
• blocking t : block indefinitely to acquire lock
• blocking nil : do not block. Rather than returning nil, should signal error of type lock-held if lock is held, such that the calling function could then handle appropriately without storing a return-value from the failed lock acquisition request
• blocking {integer} : block for a duration specified by {integer}, and if timeout, then signal error of type timeout-exceeded
• ....and that may then also be applied in a new `WITH-MODAL-LOCK` macro, as well as underlying `ACQUIRE-MODAL-LOCK` function
• Alternate to Bordeaux Threads:
• Threading in cl-async [github]
• Extended with a BT-like interface in Green Threads
• CPS: Continuation Passing Style [multscheme]
• In operating systems applying a pthreads threading model, this may provide an interface onto an underlying PThread implementations, as via cl-libevent2 and transitively, libevent
• libevent provides a platform-agnostic model for development of asynchronous programs onto C
• As far as a portable timers implementation in recent revisions of cl-async : See also  delay / with-delay (?)
• The data flow programming language, in its abstract graphical representation, could be implemented as an extension of the abstract graphical syntax and the underlying semantics of the Systems Modeling Language (SysML) ... as SysML being implemented with a metamodel extending of the meta-metamodel defined of the Metobject Framework (MOF).
• Alternately, a SysML view for the data flow programming language's data flow graphs could be added later.
• This may extend, indirectly, of de.setf.xml -- with de.setf.xml providing an interface for parsing the XMI schema and the XMI schema then serving to present a structured interface for processing and I/O onto metamodels serialized onto the standard MOF/XMI binding , with any number of vendor-specific conventions in the same.
• An implementation of the Object Constraint Language (OCL) should be developed as part of the same -- such that may apply the ATN parser, such that is applied in de.setf.xml -- the parser implementation in the OCL implementation therefore remaining aligned with the XML implementation
• This data flow programming model may  of course be implemented with extensions onto McCLIM, for managing interactions with a data flow programming graph, as via a CLIM application frame.

In parallel to the matter of thread-local slot value locking: While I was developing some notes as with regards to a lock ticket caching framework -- and a more generic object buffering framework -- as to address a question of how a program may provide an interface for controlling access to the slots of  buffered object, such that the buffered objectwould be simultaneously accessible in a buffer cache and from there, accessible in any number of threads of a program, as well as being accessible broadly in the data space of the containing process -- I had developed a question as to how and whether it may be possible to control access to a region of memory. In regards to how that may be approached in software programs developed on the Linux kernel, my question -- as such -- was promptly answered, on discovering the shmget(2) and shmctl(2) manual pages, as well as the useful  shm_overview(7) such that provides an overview of an independent SHM interface providing file descriptors for shared memory segments.  I would denote some additional caveats to this matter, as well:

• The  shmctl(2) manual page, specifically, describes some of the structural qualities of the following structure types in the Linux programming environment:
• The C structure type shmid_ds 
• Application: This type appears to be used for providing information about the Kernel's implementation of the SHM interface. For instance, there are some structure slots for recording of times and process IDs (PIDs), within the shmid_ds structure type
• The shm_perm slot provides further structure, as denote in the following
• The C structure type ipc_perm
• This type uses the key value as applied also with shmget(2)
• This type also provides a record for UID and GID values as well as flags for access permissions defined onto a shared memory segment
• Consequent to a further study of the shmctl(2) manual page, it may seem that the shmctl() function is defined for purpose of reflection onto system-wide registers with regards to shared memory allocation
• An orthogonal question: Onto what platforms other than Linux is the Linux SHM interface considered portable?
• BSD?
• QNX?
• It's not the same as mlock(2)
• Application: Ideally, there may be a compatibility interface defined between values used in  shmget(2) and similar SHM functions, and values used in mlock(2). Such a compatibility interface may or may not exist, presently, within the body of existing work in free/open source software and systems
• mlock(2) may be applied in at least two manners of usage case
• To prevent a memory segment from being paged to disk, as to ensure that data in the memory segment will not be recorded in any permanent medium, namely towards applications in data security
• To ensure that a segment of memory will not be paged to disk, as towards ensuring a deterministic timing within the calling program, for access onto the same segment of memory -- as towards applications in a realtime operating system (RTOS) environment, such as for embedded computing. As a further reference, to that effect: sched_setscheduler(2)

This outline, of course, does not present a full interface onto SHM in Linux, for any single Common Lisp implementation. The previous outline may serve to develop some further knowledge, towards some questions with regards to memory management, within any single Common Lisp implementation, viz a viz:

• One  "first question", as towards the origins the previous outline -- more broadly, as towards preventing unwanted access to regions in a program's data space -- in that regards, towards a design for data security within Common Lisp programs. 
• The question, in short: How can an interface be developed for controlling access to memory registers within a program's data space, in a Common Lisp program on any single operating system platform? 
• Nothing to compete with the Java programming model, certainly, though Java also defines some controls for data access, at least insofar as with regards to definitions of Java fields and Java methods in Java classes. The author is not presently aware of any similar SHM interfaces in Java.
• A second question, as contingent around the matter of RTOS applications: 
• The question, in short: How can memory be locked, within a Common Lisp program -- whether permanently or temporarily -- as to not be shifted in the data space, within garbage collection processes?
• This is orthogonal to the question: How can memory be locked, within a Common Lisp program, as to not be paged out to the system's page area?
• The "second question" is notably a naive question, it demonstrating some assumptions as to what side effects a garbage collection (GC) process may produce, within a Common Lisp program. Namely, there is an assumption that an object's object address may change within the duration of a Common Lisp program -- assuming that an object in a Common Lisp program may not be left where originally created within a program's data space, after completion of any single GC iteration.
• Of course there would be some orthogonal concerns, and perhaps some orthogonal design concepts, for instance:
• Is it possible to define a specific region of memory as being locked with mlock(2), and such that that region of memory may be used for allocating multiple Lisp objects? 
• May that serve to provide a methodology for implementing a non-paged memory IO region wtihin a Common Lisp program?
• May it serve to allow for a tunable efficiency in applications, such that mlock(2) may not need to be applied at every time when a new Lisp object is allocated? 
• If a shared memory control interface would implemented, in parallel to this feature, of course the shared memory control interface may produce some side effects as with regards to this feature's implementation -- for instance, in that an access-controlled region of memory may be effectively contained within the mlock'd memory region.
• There may be some additional concerns addressed, as with regards to manual memory management in Common Lisp programs, for instance:
•  That  if there may be an application in which one cannot simply cons and forget and leave the garbage collector to clean up the memory space for unused objects
• ...then as well as the implicit memory allocation of creating a new Lisp object
• ...a Lisp program may provide an interface for manual memory deallocation, thus towards both
• obviating the burdens for the garbage collector and also 
• allowing for a deterministic procedure chain, insofar as for memory management within a Common Lisp program
• This can be implemented with requirement for multithreading.
• An explicit memory deallocation thread may be implemented
• ...as to be coordinated in scheduling alongisde the garbage collector
• ...such that it would be accompanied with rigorous definitions of memory deallocation forms, for ensuring that objects created for "one time use" within a single lexical environment will be explicitly marked as to deallocate when control exits from within the same lexical environment.
• ...though that would require a storage of a separate "to-deallocate table" essentially separate to reference-counted memory -- lazy references? -- and a methodology for iterating across the same table, perhaps alternate to a methodology of scanning Lisp objects recursively for count of object references and recursively deallocating those denoted only as "not referenced".
• ...and may be applied with an functional interface, parallel to cl:gc, rather such as foo-mem:prune
• ...such that an application applying the memory prune function may be exist in parallel to applications not doing such explicit memory deallocation.
• ...and should be accompanied with a conditions model, such as for when   foo-mem:prune would be applied on any object that would contain, as an n-ary  referenced object, any object that would be known as that it cannot be pruned, for instance any definition of a class defined in the cl package
• ...and must also be accompanied with a lengthy description of how foo-mem:prune would function on individual objects to be pruned
• Note: Reference vs definition -- for instance, that a reference to a string is not a string object itself
• Essentially, this may serve to develop a concept: Memory management for objects referenced within only a single lexical environment
• Ideally, this should be implemented as to not entail any overhead for "Reference counting".

Certainly, a Common Lisp interface on the SHM features of the Linux kernel may be implemented as a layer onto an interface onto mlock(2) -- and so, the development of the mlock(2) interface could effectively precede the development of the SHM memory control interface. Also clearly, such extrnsions would need to be implemented in all of an implementation-specific manner, as onto the memory management features of any single Common Lisp implementation. This, then, would certainly require much of a detailed study onto those same features, and perhaps an application of the C programming language.

Some further notes in documentation should be forthcoming, to that effect, as may be published in this web log, henceforward. The author proposes to limit the study onto two Common Lisp implementations specifically:

• Steel Bank Common Lisp (SBCL)
• Clozure Common Lisp (CCL)

...at such future time as when it may be immediately feasible as to address the following procedural outline into an implementation:

1. To begin such a study of memory management, on those platforms.
• Ostensibly, to develop a series of SysML models for describing the conventions applied in memory management on those platforms
• UML class diagrams for illustrating structures and relations of explicit and inferred data types (e.g. VOPs in CMUCL and SBCL)
• SysML block diagrams for developing a block/port-oriented view of memory and memory management  in the respective Common Lisp implementation
• Onto CCL, block diagrams illustrating of qualities of the FFI interface
• State Charts in SysML for describing memory management in terms of finite state automota
2. To develop an interface for an  mlock(2) locked region of memory in a program's data space
3. Implicitly: To develop a Common Lisp interface onto an operating system's underlying authentication and authorization (A2) model
• To furthermore extend that interface onto the A2 procedures of Kerberos 
4. To develop an interface for an SHM controlled access to memory within a program's data sapce
• To develop such condition types, deubugger features, and other features unto the Common Lisp semantics, such that may serve to simply the programmer's view of the memory access control forms 

If the reader may wish to inquire as to why those two platforms are specified, in this article:

• Both of those platforms may be applied on an ARM microprocessor architecture
• ARM, in turn, is applied within a number of embedded computing platforms, including mobile phones
• Although there are additional Common Lisp implementations available for the ARM architecture -- including ECL -- it may be feasible to limit the study to, essentially: 
• One implementation of or deriving from CMUCL, as with SBCL at the original "Point of fork"
• This should be approached with an observation about signals, interrupts, and foreign threads in SBCL -- as denoted as being problematic for an interface onto a Java Virtual Machine, at the web site for CL+J 
• This should be approached, also, with an observation as with regards to the newer thruption model in SBCL, and related features defined in recent editions of SBCL
• One implementation deriving its implementation more broadly from LibC, as with CCL and its own respective foreign functions interface
• This may be approached with consideration: 
• That the Linux Kernel is implemented in C
• That the fundamental interfaces to the Linux Kernel are provided as for C programs
• That the FFI model developed in CCL may applied in a prototype fork for and towards applying such extended memory management procedures as denoted in the previous outlines in this article

Of course, it would be impractical to assume as if an extension could be addressed instantaneously onto two separate Common Lisp implementations, if only a single developer is developing the same extension. At this point in the article, the author arrives at a point of decision as to which Common Lisp implementation the author would wish to focus on, first, if to develop such an extension. That question, then, may be pushed further down the effective stack, with a couple of corresponding questions:

• How may a mobile application development model be developed in free/open source software, for supporting development of mobile applications and desktop applications with Common Lisp?
• How may CLIM be applied within such a model for mobile application development in a free/open source regards?
• How may that be extended, furthermore, in applications of "new" embedded computing models, such as may apply the BeagleBone Black platform, Gumstix, or any other single-board computing model capable of running a Linux operating system?
• How easily can CCL or SBCL and McCLIM be installed onto an Android device, for purpose of development testing?
• How easy would it be to use the CLIM REPL, in such an installation?
• How many separate concerns may be addressed onto CLIM, as for design of mobile human computer interfaces -- in whatever regards, if as an alternative to conventions developed of popular desktop computing interfaces? 
• How and how well may CLIM be integrated with an on-screen keyboard, as of a tablet PC or a notebook with touschscreen?
• Would it not be useful to include a modeline -- even if it would be a 'hidden modeline' of a kind -- onto every single window created, in such an appliation of CLIM? Then how would the 'meta' key be implemented, for key input to such a modeline?
• How can a commercial interface be developed, onto such work, and it not be limiting towards the free open source nature of the software that would be applied in such work?
• Sidebar: "Free/open source" does not imply "Insecure"
• A deterministic model will not be illustrated for that thesis, in this article
• Sidebar: Incentives?
• Data-secure computing for small/medium enterprise - referencing strongSwan, Kerberos, and JacORB as providing support for Kerberos and SSL onto CORBA
• Games programming for mobile platforms, in Common Lisp? 
• Can we make it look more like Half Life? Should we?
• What about music?
• What about folk music?
• What about educational applications developed albeit with a novel game-like interface but lending towards any actual, fundamental concepts in mathematics, if not also towards the material sciences?
• What wonders may await, in the literary works of Charles Babbage?
• What wonders, in a view providing of an implicit sense of gender neutrality, if not a broader sense of cultural neutrality, with regards to mathematics and science? barring any discussions lending immediately to a maturity of nature.
• Furtherance of concepts in the state of the art?
• IDE development in the heterogenous systems programming environment
• Towards implications for the software development environments in applications of virtualizaiton and software-defined networking (SDN)
• "Because CORBA"
• Beginnings of discussion with regards to community support, if not for further commercial support for Common Lisp  applications on mobile platforms?
•  "There's the kicker"
• Existing services for issue support may include:
• YouTrack
• Bugzilla
• Request Tracker
• GNATS
• Debian BTS
• Bug tracking in Canonical's Launchpad system
• May entail some platform-specific focus about Linux
• The following mobile platforms implement Linux:
• Maemo
• Android
• Fire OS (Kindle Fire)
• Firefox OS
• Chromium OS
• Any single single-board computing platform on which Linux is available
• BeagleBone Black (BBB)
• Can run Android, more specifically. See also: Rowboat
• Raspberry Pi (RPi)
• Gumstix
• Etc.
• RTOS features "To be determined" by platform (TBD)
• Focusing on the Android platform, specifically, there may be an interface available for bug tracking onto any single Anrdoid app store (TBD)
• Questions with regards to tools
• A hypothetical model for capturing results of an application error: Fork, save diagnostic data-optionally save entire Lisp image, and debug on 'Own hardware"
• Revisions for "Other users" : Do not save session-local data within diagnostics; Do not save Lisp image; ensure full authorization and authentication with upstream issue tracking agency, in network transactions transmitting of diagnostic information
• Debugger hook : How to apply that usefully on a mobile platform?
• Usage Case - Developer's mobile platform
• Context: Prototyping and testing
• Context: Unexpected situation in program
• Usage Case - User's mobile platform
• Context: Regular application procedures
• Context: Unexpected situation in program
• Debugger hook   How to apply that  usefully, for server diagnostics?
• Data models : How to "flag" session-local data values, so as to prevent their printing or storage onto media outside of environment of a running Common Lisp program?
• Systems models : How to securely and conveniently (?) encrypt a saved Lisp image?
• Further implications onto design and development of digital platform operating systems?
• How to integrate developer tools, in a novel manner, with Xen? 
• cf. Xen Dom0 
• Emulator as Dom1 instance
• Xen must be (?) installed directly on platform hardware
• Orthogonal to: Microkernel design.
• cf. Amazon Web Services
• Application of Xen

To this point in the article , the article has diverged from the original topic of developing a data flow programming model in Common Lisp.  Figuratively, the eSym project might represent some figurative icing on the figurative concha otherwise described in this article. The majority of such tasks as would entail an extension of interfaces onto the Linux kernel -- as addressed in this article, albeit superficially -- those might be approached albeit without a cup full of sugared bread, but with a substantial portion of documentation regardless.

This article has described a substantial number of individual concepts and related task items, such that may be addressed into development of an essentially arbitrary number of source trees.

This is developed under the MetaCommunity project, towards a further goal of developing a comprehensive architecture for application development in Common Lisp, and an orthogonal goal of reviving the design of MIT CADR for application onto contemporary microprocessor architectures, denoted as the CIIDR project.

An Introduction to the MetaCommunity.info fork of McCLIM (Overview - Initial Outline)

Ed. Note: This article represents a preliminary outline for an overview about the MetCommunity.info fork of McCLIM, focusing primarily on the YouTrack InCloud instance presently applied for management of the same fork project.

Pending subsequent revisions of this article,  this initial revision of the article may serve to provide, at least: Some web references onto task lists as created for and of the same project; an overview about YouTrack, in basic outline format; an overview towards the structure of a meta-IDE project developed under the MetaCommunity.info domain.

Items denoted wit {Bracketed Text} will be subject to revision, in subsequent versions of this article.

Overview

{i.e. topical introduction}

{GUI Domain in Common Lisp Application Development}

{McCLIM development}

{MetaCommunity.info (MCi)} {work journal}

{MetaCommunity.info fork of McCLIM}

{Sidebars: Traditional CLtL HCI APIs including: McCLIM; Garnet; Cells GTK; Graphic Forms}

{Sidebar: McCLIM' gtkairo backend; FirefoxOS}

{Projects Management Domain in Common Lisp Application Development}

{Concepts for which there are some exacting, conventional "web service bundles"}

• Repository management (Github; GitLab; ...)
• Continuous Integration (TeamCity; Travis CI; Jenkins; ...)
• Issue Tracking (Gnus; RT; Bugzilla; YouTrack; ...)

{Concepts for which there are assorted tools - applied at project managers' own discretion}

• Documentation development {authoring, editing, publishing, maintenance}
• Release management {develop=>test=>release=>maintain}
• Distribution management {binary distributions - archives/packages/installers by platform and version; source distribution available via repository management service}
• Web presence management {social networking; documentation; resource distribution}
• {For web hosting, alternatives include}
• Static-Content Web Site
• Hybrid Static/Dynamic Content Site
• PHP
• Python
• JSP
• ...
• Web Site Published via Java Archive (formats; JAR, WAR, EAR, ... varying by container)
• Variation of hybrid static/dynamic content site 
• {JSR-... - Java servlets}
• Web Portal
• {In Java} A variation of Web Site Published via Java Archive
• {JSR-..., formal portal request/response cycle}
• Alternatives
• JetSpeed {static portal}
• ...
• Liferay
• {In Other: In programming languages other than Java, portal implementations include Drupal (Python), ...}

 Ed. note: In a sense, "Issue tracking" presents a "Meta-concern," applicable at all phases of a project's formal duration.

{YouTrack} {Stand-alone} {InCloud}

{YouTrack InCloud} {Documentation} {Qiuck Start} {Presently, InCloud is backed by YouTrack 5 [xref]}

{YouTrack License Model}. {10 user limit for 'Free' editions, in stand-alone or InCloud installation}

{MCi instance at YouTrack InCloud (Guest login enabled)}

{An Outline Onto Concepts Implemented in YouTrack}

{Project information structure at YouTrack}

• Projects
• Items
• Swimlanes
• Issues
• Tasks

{Conceptual View}

• Colloquially, Agile Project Management Concepts
• Scrum
• Sprints
• ...
• ...
• Project Life Cycle
• ...
• ...

{YouTrack Web Interface}

Items of note in MCi McCLIM YouTrack InCloud service:

• Dashboard (configurable by users)
• Agile Boards
• Example: Agile Board for Issues noted to initial 0.9.7.1 sprint
• Example: Agile Board for Issues not scheduled to a sprint
• Task List
• Example: All Swimlanes, Tasks, and Issues
• Task Searches
• Example: Unresolved, Unscheduled issues related to MCi McCLIM Fork 

Article Metadata

Revision History

• 1.0 (20 Nov 2014) - Basic Outline
• 1.1 (20 Nov 2014) - Web and Metadata
• Add details onto web presence management , focusing on web hosting models
• Add Article Metadata Section
• Add initial tags to article: MetaCommunity, McCLIM, CLIM, ANSI CL, CLtL2, YouTrack

Towards an IDE Model for McCLIM (Draft 2)

Outline:

• McCLIM
• implements the Common Lisp Interface Manager (CLIM) within a free/open source software licensing model
• available with an "adapter", formally a "graft" for a number of window systems and GUI platforms, including X11 (CLX) and Cairo UI (GTK Cairo) 
• CLIM defines the class, application-frame
• The class clim:application-frame may be extended to define a class, ide-frame
• The class ide-frame may be defined such as to provide a convenient baseline for development of graphical IDE view elements
• A configuration parser  may be defined as associated with the class, ide-frame
• IDE view elements may be defined in a manner reminiscent of graphical application interface elements as defined within popular IDE tools, such as:
• Filesystem view
• parameter: Root filesystem pathname (pathname directory)
• parameter: Filesystem element filter function 
• arg: filesystem pathname
• return: boolean "display-p" value
• File view
• parameter: File pathname
• associated concept: File view controller
• define as a CLOS class, file-view-controller
• dispatch on filesystem type, e.g. (defgeneric get-file-view (file controller))
• initialize class and bind to *default-file-view-controller*
• reference class of file view controller within IDE configuration data
• Workspace view
• Extend on workspace definitions created by Eclipse IDE
• define parsers for workspace metadata as created by the Eclipse IDE 
• include "check" for "workspace in use", preventing access to files within a "workspace in use", to minimize concurrency conflicts during file editing
• Workspace URI, index, and structure -- CORBA (TO DO: IDL Interfaces)
• SCCM views
• SCCM local source tree view, and SCCM repository view
• dispatch SCCM view selection per type of SCCM system in use within a root SCCM directory
• incorporate with an interface (FFI, shell commands, or Lisp) onto each supported SCCM model (cf. Emacs VC Mode)
• Observe that a local source tree for an SCCM system such as Git would be, simultaneously, a local source tree and an SCCM repository 
• SCCM repository URI and index system -- CORBA (TO DO: IDL Interfaces)
• Toolchain views
• Reminiscent of Eclipse IDE perspective definitions (???) but focused on discrete classes of toolchain elements
• Toolchain category: GCC
• Tooclhain category: Lisp interpreter
• ...
• To do: Prototype sometime after defining a CLIM adapter i.e. "graft" and/or CLIM widget layer onto CommonQt (?)
• Requirement: Suitable HCI responsiveness
• Alternate consideration: Native XLib FFI interface (CFFI)
• Implement: X11 SHM interfaces
• Limitation: Further complexity in CLIM HCI model on Microsoft Windows platforms
• The Microsoft Windows Explorer Desktop Shell is not X11R6
• cf. XMing and/or Cygwin
• Limitation: Applicability of Shared Memory models in Common Lisp applications
• Objects referencing shared memory
• Shared memory references should remain immutable (?)
• Alterate consideration: Use GTK Cairo interface on Microsoft Windows Platforms
• GTK Cairo integration for mobile OSes?
• Firefox OS (?)

Sharing some simple notes about Maxima

Maxima

• Formally, Maxima is a computer algebra system
• Derived after MIT Macsyma -- see also, A Brief History Of
• In a sense, An extensive mathematics platform in Common Lisp
• System Definitions
• maxima.system : Uses MK:Defsystem
• maxima.asd : Uses ASDF
• Maxima and CLOS?
• CLOS and CLIM?
• CLOS and OWL?
• OWL, RDFS+OWL inference, SWRL, and mathematical interpolation?
• CLOS and data processing tools onto ...
• the Sloan Digital Sky Survey? 
• Autonomous navigation in "Outer space"?
• FFT, signal domain transformations, Planetary Data System, and asteroids
• Three uses of CL:DEFCLASS, all in numeric.lisp
• Numerous uses of CL:DEFSTRUCT
• Some ANSI CL implementations use CLOS implementations derived from PCL
• PCL, CL:STRUCTURE-CLASS, and CL:STANDARD-CLASS
• MOP and FUNCALLABLE-STANDARD-OBJECT (sidebar)
• Maxima and "not directly Lisp"
• Maxima 'mac' and 'dem' files - see subdirs of 'share'
• Documentation?
• Maxima GUI
• TCL/Tk (?)
• Maxima and CLIM
• REPL integration and formula display: share/contrib/mcclim
• Serialization, integration with other computer algebra systems
• Maxima and MathML: share/contrib/maximaMathML

Simple notes are simple.