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.

Design Document: Transforming YAML to OWL

In an ad hoc regards, my having begun a project[1] in which one of the goals will be, technically, to transform a set of YAML models into a set of OWL ontological models -- all of a set of simultaneously legal and public information items about the structure and the proceedings of the United States Congress -- there becomes a goal, sort of iteratively, towards defining a methodology for translating "That YAML model" into a a single ontology model -- likely that may be stored as separate files, one for each of :

• An ontology about the United States Congress as a whole, including:
• The United States House of Representatives
• The Senate of the United States of America
• Committees of the House and of the Senate
• Sessions of the Congress
• Leadership Roles in the Structure of the Congress
• Congressional Membership
• Political Parties in the US
• US States
• Congressional Districts, in Each Congress (in a model organized into one file to each US state)
• Formal public profiles about members of the Congress (GovTrack, Washington Post, etc) i.e "Social media"

Some Caveats

Caveat 1: Not About Lobbying

This project will not be endeavoring to venture onto the "Bling-bling" or alternately "Hot-Button" topic, campaign financing -- not at the scale of the PAC, and not at the scale of any manner of crowdsourcing. Certainly, campaign financing is thoroughly addressed in an existing number of existing web information resources. This project shall focus, rather, about the formal structure and the proceedings of the US Congress, in an interest of developing a structural model of the Congress -- a model constrained within the effective model syntax of the Web Ontology Language (OWL) -- in developing an OWL model that may be made reference to, for effective application in development of web content resources. This would be, principally, towards fostering a sense of understanding for US citizens, as about the US Congress as an entity representative of the United States, as well as for fostering of US citizen involvement in the democratic processes of the US federal government.

 

Caveat 2: Not POTUS or SCOTUS

This project, specifically,  shall not be focusing about the US Federal Executive Branch, and neither about the US Judicial Branch.

 

Caveat 3: Congressional Record Annotation Engine?

This project may later endeavor to develop a model for processing of documents published in the formal Congressional record, in the interest of applying  any number of topically focused models -- e.g AGROVOC -- in developing a machine generated, topical annotation layer onto the Congressional record, in application of existing, expert topical knowledge models, for fostering a broader public understanding about topics addressed in the Congressional record.

Ed note: In regards to this item, specifically, it should be considered, whether and how an ontology-focused model, as such, could in any ways extend on the functionality available of a conventional, flat/full text search engine. Concepts of the ontological knowledge model should be thoroughly addressed, in that analysis, such as: Knowledge and Information Structure; Inference and Entailment; Subsumption, and Extensibility, and the Open Universe Model.

Technical Outline: YAML to OWL

An information model in YAML structured markup format may be transformed to instance of OWL ontology model, using one or more programming languages. This project shall use Java.

Implementation note: The processing of the YAML input stream could be managed with SnakeYAML. Serialization to OWL could be performed via OWL API or Apache Jena.

Deriving Instances, Assigning OWL Classes

It should be noted that input YAML data would not define the entire ontology, itself. Rather the YAML data would be used in deriving OWL individual objects, each implementing of one or more OWL classes from within an existing ontology.

The pairing between YAML and OWL may be implemented in conjunction with a structured table, such that may be initialized exactly one, at runtime -- essentially, assigning one or more OWL classes C1..Cn to a single, structured, ad hoc YAML input path, P. In the effective processing model applied onto the YAML input, each node in the YAML input may then be iteratively scanned for each P in the table, as to generate a set of OWL individual instances M1..Mn such that each M would be of a class C1..Cn for each such P.

Step 1: Initializing XML DOM Nodes from YAML

That initial scanning method may be accomplished by first initializing an XML document object model (DOM) document, at runtime, derived from the input YAML model -- regarding the YAML model, then, as a source of instance data for within the DOM document. and the DOM document as it providing a programmatically useful structural model for the initial instance data.

The OWL-class-to-input-data table {{P1,C1...Cn,} ...} may then be implemented with each P being of type xpath expression. As for whether Cn would be implemented as of type URI, each referencing a single OWL class -- "YAML to OWL" -- or alternately, each Cn being implemented as exactly one Cn to each P, with Cn then denoting a Fully Qualified Java Class Name -- "YAML to Java." This processing model will prefer the latter implementation. In the "YAML to Java" implementation, each Cn may then make reference to a set of C'1...C'n each denoting an OWL class.

 

 Step 2: Initializing Java Objects from XML

In the "YAML to OWL" approach, C1...Cn may be defined as being each of type URI -- each URI, then denoting a specific OWL class within an input types ontologly. The respective types ontology may then be initialized within the Java runtime, at any time before the assignment of data properties, within the respective OWL engine -- such as OWL API or Apache Jena, for instance. 

In either of the "YAML to OWL" or "YAML" to "Java" approach, a loose coupling should be implemented between the respective Java class and the set of OWL classes.

 

Step 2.1: Deriving Java Class Instances from Input DOM Nodes

Alternately to the "YAML to OWL" methodology denoted in this article, then as in order to make effective use of Java method overriding within the processing model, C1 may be defined as each a single Java class, with C then serving effectively as a container of OWL Class URI C'1...C'n.

 

Step 2.2: Assigning OWL Properties 

... specifically, Object Properties and Datatype Propeties 
...  to each OWL Individual Instance Derived from the DOM model

After each Java object N'1..N'n is initialized, each of a single Java class C1..Cn, then the assignment of data properties -- as would be assigned, each, onto an OWL individual instance represented in N'n as derived of DOM node Nn -- the property assignment procedures may then proceed in one of at least two alternate approaches:

1. With a constructor for C processing the DOM node N of which N' would have been derived, in the initial assignment of C to P, then assigning OWL properties A1..An to N'. 
• This would be in a model of assigning OWL object properties and data properties (P) defined the input ontology, 
• Each property defined in the input ontology would then be mapped onto an input DOM node N and the derived instance N'
2. Similarly, but rather than with the OWL property assignment being encapsulated within the constructor for C, instead with the OWL property assignment being encapsulated into a single property assignment engine method, then encapsulating calls onto any exacting property assignment methods -- this description, necessarily differentiating OWL object type properties and OWL data type properties. 

Focus: Object Property Assignment

The generic object type properties assignment method would bear some particular attention, whereas any object type property assignment method, in this model, may be effectively required to reference -- in (subject, predicate, object) form, similarly (N, A, M) -- as given a single Java subject object N, as would be provided to the respective property assignment engine method defined to the class C of N, and for each predicate object property A, as selected of that engine -- that the object M may be available only as an object reference, towards an object not yet initialized within the result ontology.

The input model -- whether in a YAML text format or derived DOM object format -- the input model may denote any single reference object of (subject, predicate, object) with a string key code for the object. To effectively pad for that concern, within the object type properties assignment step, the property assignment may be conducted not until after all N'1..N'n would have been initialized.

Considering that in each element of the (subject, predicate, and object) trie of any single OWL object property expression, the reference to each of the subject, predicate, and object is denoted with a URI, whereas the reference in the input YAML model is rather encoded as (subject, predicateCode, objectCode) then the procedure for reference translation, in this model, must effectively represent a translation from numeric object code to object URI.

Step 2.3: Assigning OWL Class Identities to Java Objects

Effectively, the assignment of C'1...C'n OWL class identities may be implemented as a sort of property assignment procedure, in itself -- as iteratively, onto each Java object derived from the input DOM model, that derived from an input YAML model, in this example.

This document will denote as in a sidebar that one or more OWL Classes may be assigned directly  to any single OWL Individual node, moreover that zero or more OWL Classes may be derived of a single OWL Individual node, as by way of directed inference applied onto the input OWL model. The model for deriving an ontology of information about the Congress -- in the methodology as described in this article -- will be implemented only with direct OWL class assignment.

In sidebar, briefly: As an abstract example of the derived class model, a derived class may be defined, "Senators of North Dakota", such that the OWL class of that derived information object class would be defined with SWRL inference rules, namely as such that the OWL class thusly defined would be defined as to denote Congresspersons who are Senators elected to represent the state of North Dakota, as would be across the entire timeline provided of the model itself -- as in this example, deriving from the input YAML model. It may seem that the greatest strengths of the OWL abstract data model would be found in such a capacity for defining such derived classes within an OWL abstract data model. Not in so much as a tedious "Data mining," rather that an OWL inference model -- such as the SWRL inference model onto OWL, specifically -- that it allows for extraction and derivation of discrete objects representative of structured knowledge, from within a broader object model representative of structured knowledge.

(Draft 2 and final, of this article)

 
[1] Onto Ontologies, the Constitution, and the Congress. DSP42. 2014

Onto Ontologies, the Constitution, and the Congress

Contemporary Sidebar, or "Big Brother's Big Ears"

But first, a question: Is PRISM anything I would like to speculate about? Absolutely not! If the NSA would be voluntarily transparent about the science and technology being used by the NSA, it would sure be a different kind of National SecurityAdministration, I'm sure. Until that time, I can only interpolate -- not so much as to to speculate -- of anything I've ever read or read of[1], in so much very serious web content. It's not a happy chain of thought, that, but certainly it's a comment to the state of the art, in this epoch? Nothing about anyone's "wargaming", moreso about information science.

KR, KM, XML, RDF, and OWL, as Topics

So, "that aside," There's a long history to the development of knowledge modeling and knowledge representation, in academia -- much summarized, and summarized again, throughout academia. This article will not endeavor as if to to duplicate any of those multitudinous items in academia. In a practical sense, recently the World Wide Web Consortium (W3C) developed, specifically, the Resource Description Format (RDF), later the Simple Knowledge Organization System (SKOS) as then extending on RDF, and later the Web Ontology Language (OWL), later SKOS then effectively reexpressed as an extension onto OWL.

Sometime in 1776, there was a certain issue of national independence that was begun, followed by the drafting of exactly one US Constitution, followed by the development of one United States of America. Around that time, the US Congress was defined, as delineated specifically in Article I of the Constitution of the United States of America.[1]

Sometime more recently, the Congress developed information systems such as would publish proceedings of the US Congress, in XML format[3] More recently still, the United States project at Github[4] has published structured information about the Congress and the proceedings of the Congress, in structured YAML format.[5]

2 (base 10) + 2 (base 10) = 100 (base 2) therefore....

Onto an Ontological View of the Proceedings of the US Congress

There's a lot of information in the @unitedstates YAML files about the Congress. Though in browsing the project's README file, it might seem like simply a flat table, but there's a depth to that public information, such that becomes to a nice concept of linked open data[6] in a legally public regards. Such as: Congress membership, Congressional sessions, Committees, Political party affiliations, and much that could be rendered in OWL datatype properties for creating convenient URL links onto existing, simultaneously legal and public knowledge resources, online. I'm not sure if Julian Assange would be impressed by that or not, but to continue.... Those @unitedstates YAML files can be processed, easily enough, to a definition of an ontology about the Congress and the proceedings of the Congress. Why would that be useful, though?

Article I of the Constitution of the United States of America is the Article of the Constitution of the United States of America in which the Congress of the United States of America is defined.[2] Article I precedes Article II -- the latter, in which the Executive Branch of the Federal Government is defined. The authors of the Constitution had saw fit to describe the Congress, before describing the President. There is certainly a matter of precedence, illustrated in that decision. It's quite significant to the concern of State's Rights and of States' representation in the Federal Legislature. With the recent bunch of actions by the Department of Homeland Security (DHS)[5] in US states, the concern for states' rights is more clearly poignant than ever, as a feature of the US democracy -- truly more clear than ever, in this author's own lifetime. That concern is likewise represented in the very design of the United States Congress.

Therefore, the author proposes: It is a good time to start paying a lot more of attention to the US Congress. 

Consequently, the author proposes: That the "Bar napkin sketch" I've been carrying, so to speak, of an ontology about the federal legislature, that now is a good time to begin developing that. Considering the availability of structured legal and public information in that domain,[6] it could even seem trivial.

This would be, in effect, the announcement of that project.

  
[1] having read of: Inyaem, U.; Meesad, P.; Haruechaiyasak, C.; Tran, D., "Ontology-Based Terrorism Event Extraction," Information Science and Engineering (ICISE), 2009 1st International Conference on , vol., no., pp.912,915, 26-28 Dec. 2009
[2] Constitution of the United States. NARA
[3] XML.gov at xml.fido.gov
[4] @unitedstates. A shared commons of data and tools for the United States. Made by the public, used by the public
[5] @unitedstates. Members of the United States Congress, 1789-Present, in YAML, as well as committees, presidents, and vice presidents.
[6] http://linkeddata.org/
[7] notes that I've been able to compile as to share, this week, at my Bring Back Lady Liberty blog: Deferred Action for Childhood Arrivals (DACA) - a DC Politics Story