Thursday, July 23, 2015

Towards a DITA OT Port for FreeBSD -- But First, The Larch

Corresponding to a beginning of a development of a personal business plan, formally starting today, I've set aside my  own edition of the [plug start] Samsung Galaxy S 8.4 Tablet -- an Android tablet -- and its seat-friendly, tabletop-friendly, all-around outdoors-friendly Griffin All-Terrain case [plug end] -- furthermore, leaving aside the Evernote app -- likewise, to sit down at my FreeBSD notebook -- for a short time -- indoors. It's a kind of a "Pivot day," in my own small, individual corner of the world. I've subscribed to Safari Books Online, and have begun to develop an ongoing books list.

In beginning to read one item in that list, I've queued up what is my first book to read about the Darwin Information Typing Architecture (DITA), in my own Safari books queue, namely the text: DITA Best Practices: A Roadmap for Writing, Editing, and Architecting in DITA.

Corresponding to that new books subscription, yesterday I'd begun developing a draft edition for another 'blog article -- that article, focusing about DITA, as in developing a concept of DITA architecture and DITA in applications. That was in using the Blogaway app (Pro edition), on my tablet.  I'm afraid it may as well remain in an unpublished draft edition, that article. Candidly -- in no short time after I've signed up with the Safari Books subscription service and begun reading about DITA -- presently, it's developed from an academic pursuit into a project idea. Likewise, it's such that I'd like to share about, as a project idea.

Of course, a project would not be able to take up a life of its own, in such short time. Beside the introduction that I'd tried to develop, in that unpbulished 'blog article, yesterday, but in a shorter sense of overview: Personally, I have some albeit limited knowledge about technical writing -- as namely with regards to a small number of document formats, such as the DocBook SGML DTD and DocBook 5 RELAX NG XML schema. I'm fairly well familiar with XML, more broadly, as a markup format.

Previous to yesterday, I'd read a little bit about DITA. In a sense, I'd thought it seemed like a kind of a cheerful little ray of sunshine about narrative XML documentation formats, in broad -- a topic that there might not seem to be too many rays of sunshine about, typically.  Candidly, on reading only some little about applications of the DITA schemas -- furthermore, in my being familiar with a style of hypermedia markup conventions as developed in DocBook -- I was a little put-off about some of the conventions of XML syntax developed in DITA. Mainly, there are the syntax and semantics of linking, in DITA information sets -- more specifically, a small number of elements and attributes in DITA, such that those elements and attributes may serve to provide "hooks" for content replacement in DITA processing models, as I've now begun to understand-- in a sense, those confuse me otherwise. I think there's a substantial difference in how DITA develops a concept of hypermedia linking, contrasted to the primarily ID/IDREF oriented hypermedia linking model in DocBook. I don't personally find myself able to "Leave it all to the editing platform," either -- my not being able to assume any manner of an opacity about the DITA markup format -- as I'm fairly certain that I may be editing a DITA markup file in a console-based text editor, at some point in time.

So, although those features of the DITA markup schemas may be such that I may find difficult to understand -- at least, at either of a first or second approach, in study -- now that I've found more of a friendly documentation about DITA and reviewed a couple of DITA document source trees, I'm fairly certain that I should be able to learn to proactively adapt my own hypermedia knowledge to adjust to the DITA document formats, even inasmuch as with regards to extending DITA.

 It's on that note, then, that I am still trying to write around the "Long leap" of the following tasks, as I can forsee in my own "Next nine yards" about DITA:
  1. Installing Java on my own FreeBSD notebook, with work-log, notes, and documentation references correspondingly
  2. Installing the DITA Open Tooolkit Tools onto the same notebook, likewise with a set of corresponding notes and references
  3. Likely beginning at least a local project for creating a FreeBSD port of DITA Open Tooolkit. This task, ultimately may entail a communication and further coordination with the FreeBSD Java(R) Project. As such, it's nothing I may approach in any of a too casual regards. Not to say overmuch about my own opinions of Oracle's style in commerce or software development -- however contrasted to the novel goodwill style of approach, as originally developed by Sun Microsystems -- I think Oracle's left me with a little bit of a bad impression, as to Oracle's position reportedly ever disfavoring developments in free/open source software (FOSS) namely in defense-oriented projects, and perhaps Oracle's own lack of information, as such, candidly. 
So, personally, I'm not a big fan about Oracle, and I'm not altogether certain if there is any broad Java developer community, any more, outside of Oracle ... and  FreeBSD, and a small number of enterprise web portal projects. The vibrant community that had developed around Java, during Sun Microsystems' management of the development of the Java programming language -- would it be too naive, to draw a metaphor of fracking, as for how that changed when Oracle acquired Sun?

The Oracle Java(R) launcher thing on Microsoft Windows 8.1 -- though it's cute, certainly -- it doesn't really change that impression, so much, not to my own point of view. Candidly, I still expect Oracle to be the monolithic corporation largely focused about a database platform, such that I've -- for a long time -- estimated of Oracle as a company. I don't think it makes any less of an Atlas-like shadow, with Oracle having acquired Sun. With Oracle now having demonstrated their own obvious lack of information with regards to FOSS and defense systems software, I might wish to trust Oracle to be moreover a Blind Atlas -- very worrisome, I think, worrisome if Oracle would set about to "Make New The Things."

So, knowing of a particular manner of a corporate monolith as such, looming up a little ways northward in California, and with some much of a knowledge of a broader world, I'm afraid I'm unable to join in the local Cool Team Parties. Even in avoiding any manner of a too locale-centric manner of a perspective about software development, but it still kind of "Creeps me out," about Java(R), if Oracle is really all the Enterprise as may I candidly estimate it to be.

If it may be possible to limit one's owns views to a sense of plainer principles, however -- inasmuch, to not make overmuch of a consideration as with regards to superstitions -- sure, Oracle might not be  all of the scarily opaque commercial software institution that I might think of it as. Focusing if simply on the ongoing free/open source licensing of any products previously developed or adopted by Sun Microsystems -- such as Berkeley DB, for instance, in its free/open source licensing options -- there's a matter of software licensing, orthogonal to any company's own apparently political positions with regards to software development models.

Thus, there's a foot I can find, in my own sense of knowledge about software now licensed by Oracle -- a foot, at which I may be able to disembark from my own concerns with regards to Oracle's policies. If it could seem as though Oracle could become such as, "Like Old Microsoft, but a thousand times worse," there's what I'm worried about. Regardless, the free/open source licensed by Oracle as free/open source software, that much of software might endure any such shift -- as much as of any free/open software licensed originally by Sun Microsystems.

So, in something of a sense of an organizational view,  maybe the goodwill "Vibe" that Sun developed could be just enough that it may endure even the acquisition by Oracle -- however far any developers and managers who would've been the parties directly developing such goodwill, and about a programming language moreover, however far "The Java Original Team" in and beyond Sun, may  have been put off and away from Oracle.

If I'd thought as though the film TRON: Legacy may have been all of a metaphor about Apple, perhaps it could as well be a film interpreted as if about any other Silicon Valley empire of an enterprise -- Oracle, perhaps as like a CLU character nearly making Java break out so much that it would break apart?

I don't find myself able to ignore the apparent social implications of Sun's acquisition by Oracle -- it seeming even more worrisome, after Oracle tried to toss some mud to the US DoD, as denoted in an article once reported to Slashdot, mud as if about free open source software. The "Old Microsoft 2.o?" theme, thusly, it began in my own simple point of view about Oracle.

Clearly, Oracle "Owns" Java(R)  as a trademark, today, but -- not even after the acquisition of Sun -- Oracle certainly does not own the history of the Java programming language. Thus, there's a broader sense of context, and nothing radical, about not looking too far into the Oracle.

So, maybe there's any plan for Java integration in LLVM. I'll have some research to develop, before I myself may develop any further work about Java(R) on a FreeBSD(R) operating system. The Brand Wars not begun again, they have not.

Friday, July 17, 2015

Towards a Multiply-Linked List model for Storage and Retrieval of Trie Structures {S,P,O}

Ed. Note: Clearly, this web log format does not serve to present an ideal format for presentation of mathematical notations. The syntax of the following article may be difficult to read. It should be reformatted, subsequently, to something more immediately legible in its web-facing presentation.

Earlier this month, I'd begun developing a UML model for a graph-oriented application system, namely after a matter of small confusion with regards to differing board support information about the Cryptotronix CryptoCape circuit board. The design, as such, began to by-in-large diverge from the original concern as with regards to logical and physical modeling of electrical systems. It's become, it rather seems, a design for albeit a simplistic manner of graph-oriented application framework, extending of a FreeBSD operating system

As one of the core features in that design -- as yet, the design as such being represented in a by in large incomplete and unpublished document, but here might be a start of some of a literate documentation about it -- the design features a sort of a simple, abstract binary tree model for storage of trie formatted data, as of -- in a manner or description logics -- a data format {S,P,O} for resources S and O being, respectively, a subject and an object joined of a predicate P. This format, of course, is by in large influenced of the design of the Resource Description Framework (RDF).

The abstract binary tree model proposed in the same presently unpublished design, the same tree model, in its format, is essentially of a generic format like so: {{S,P}, {P,O}}

In a sense, perhaps it may seem like an arbitrary design concept, as here it would not be immediately correlated to any logical or mathematical models as with regards to data structures and computing. Of course, the author is at least vaguely familiar with a generic, diadic format of assembler instructions.  The original design, itself, may be much like unto a cafe placemat sketch but produced in UML format.

Of course, the design may evolve over time -- much to the author's own sense of uncertainty, as to whether or not to publish the initial design resource, presently. Essentially, it's a multi-layered design -- developing some of a service-oriented view, in parallel to a design for a simple graph information service, in a manner focusing on CORBA and some of a network security model. In each essential layer, however, the design is by in large conceptually naive, and not as yet completely developed to any single proof of concept. In some of a view of  a competitive software development community, it could seem like the design is far too much of a ripe manner of chum for a sharkey web, thus it's presently unpublished.

The storage of the {{S,P}, {P,O}} model would, itself, be one feature to address of the design -- here unnamed -- in any implementation.  The generic model does not, in itself, provide any detail as to how it  may be best implemented. Broadly, and albeit without any sense of a single usage case, an application could maintain exactly three tables, of each of A={S,P}, B={P,O} and M={A,B}.

Each of A,B, and M, hypothetically, could be implemented as a sequence value -- in Common Lisp, optionally an adjustable array -- each contained within some sort of an encapsulating object -- in an abstract sense representing each of A, B, and M as a table each implemented with a vector. In addition to each of the binary object values in each relation A,B, and M, the implementation may suffix a numeric index value onto each respective table -- thus, A' = {S,P, N_A}, B' = {P, O, N_B}, M' = {N_A, N_B, N_M}.

In something of a list-oriented approach, alternately, each of the tables may be given an index value N — fig. 1

A" = {S, P, N_B, N_A} // Including N_B in A"
B" = {P, O, N_M, N_B} // Including N_M in B". Redundant 'P'
M" = {N_A, N_B, N_M} // The "End" relation

Thus, in constructing any complete {S,P,O} relation for any S, any row of B" could be retrieved in beginning at a row in A", and any row in M" from a row in B", in such an implementation. This suggest a manner of a singularly linked list.

In refactoring the design into a doubly-linked list model, A" and M" may be retained — the refernce to P, made exactly once in A" — thusly, fig. 2

A" = {S, P, N_B, N_A}
B"' = {N_A, O, N_B}
M" = {N_A, N_B, N_M}

In that design, M" would be essentially redundant, though allowing perhaps for an {S,P,O} to be referenced as a unique object independent of A" and B"'.

In a more normally list-oriented design, towards a manner of a single-linked list — fig. 3

A"" = {S, N_B, N_A}
B"" = {P, N_M, N_B}
M"" = {O, N_M}

Towards a manner of a multiply linked list — fig. 4

A""' = {S, N_B, N_M, N_A}
B""' = {P, N_M, N_A, N_B}
M""' = {O, N_A, N_B, N_M}

Once the initial design is refactored onto a list-like data model -- as reminiscent of the (CAR,CDR) semantics of lists in Common Lisp -- then the design begins to assume a sense of applicable normalcy. For an application system, the {A""', B""', M""'} model might represent a manner of a most effective baseline data model design, it allowing for a search for any of {S,P}, {P,O}, {S,O}, and {S,P,O} sequences, essentially without any further data structure definitions in the table itself.

In developing a manner of a meta-semantic view of the last table design, in the previous: Essentially, it describes a model in which regards — fig. 5

Given: {M_1,.. M_N}
Define tables {M_1, M_N} ...
* as that each table M will be defined with N+1 columns
* such that in any row n of a a table M: an index value N will be defined in the row, such that N = n
*  furthermore, in any row n of a a table M: Each of {M_a, .. M_b} will be referenced, for a != n, b != n

This meta-semantic model allows for indexing and search across all elements of any single set type structure S = {M_1, ... M_Nx} 

So, it's probably as well that the original design document has not yet been published. To resolve the original design document of all its distinct naivete in design, the design document itself should need to be suffixed with so many considerations of the technical qualities of any single implementation, it may serve to render the original design document essentially obsolete.

Not as though to leave it to collect dust for all eternity, here's the first textual design document about an as-yet unpublushed, graphical model of a graph OS.

Continuing this article as from a description of generic data structures, towards a concept about application, it may be noted that the table structure described in fig. 4 may be initialized from any set of trie structures {S, P, O}. Some of the columns in the table would be populated not of data values represented in the original input structures, but rather as to provide for a small number of "Procedural shortcuts" for optimization of searches onto each table  of {S,P,O}.

Of course, once the table as illustrated in fig. 4 would be initialized of any single table of {S, P, O} if any single update would be made as effectively onto any row N of the original table, then any number of additional data stuctures — such as would be created during the table's initialization — would likewise need to be updated, specifically for any changes in reference across any single, original {S ,P, O} data structure.

Perhaps towards a more structurally modular design of the tabular model illustrated in fig. 4, the supplemental reference fields as added to fig. 3, in this design, may be essentially separated such as to create one additional table structure, removed of redundant refences  — thus, fig. 6

A_x = {S, N_B, N_A}
B_x = {P, N_M, N_B}
M_x = {O, N_M}
C_x = {N_M, N_A} // {O,S} in {S,P,O}

The supplemental table, C,  need not include row index values. That table would not provide original reference values, but would be maintaintained as for purpose of optimization of supplememtal searches across direct {S,O} references in the table of {S,P,O}. For searches singularly onto {P,O} in {S,P,O,} the table B_x may be queried. For searches singularly onto {S,P}, the table A_x provides a sufficient set of data fields.

Certainly, fig. 6 may serve to present an optimal table structure, at least across the set of table structures described in fig. 1 through fig. 4 and fig. 6.

In the methodology of storage/reference encoding illustrated as in fig. 6,  a table group structure is illustrated. This may be juxtaposed to a singular table structure, such as may be implemented onto an SQL relational database -- fig. 7

N_a = {S, P, O ,N_N}

In the table group methodology for storage/reference encoding, structural data field elements are stored independent of other elements. This table group methodology may be more closely analogous to data structures within a Common Lisp implementation, juxtaposed to data structures of a conventional SQL relational database implementation.

In a manner of further refining the table group illustrated in fig. 6, the tables A, B, and C may be removed of cross reference values, then applied only for storage and identity of data values for each element of {S, P, O}. Data references as of {S,P}, {P,O}, and {O,S} would all be stored in separate tables, independent of the individual data object tables -- fig. 8

A_y = {S, N_A}
B_y = {P, N_B}
M_y = {O, N_M}
C_y = {N_M, N_A}
D_y = {N_A, N_B}
E_y = {N_B, N_M}

The author has, to now, assumed it would be a known axiom that each of the N_fum row index values, in each table, would be an unsigned integer value unique in the respective table. Each N_fum value, correspondingly, may be interpreted as representing a manner of structure-relative reference address for each such data value.

If this methodology for table-oriented data storage would be extended logically as with regards to  CMUCL widetag and lowtag values, individual tables within the model may be referenced of, each, the respective widetag or lowtag interpretation of each data value's type. With the respective widetag and lowtag values being normatively documented, as for portable applications, the data encoding model, itself, would not be uniquely applicable of the respective Common Lisp implementation in which it would be applied.

The CMUCL widetag and lowtag values, as effectively forked in SBCL -- directly, as forked along with the broader CMUCL source tree, from the time of the origin of the fork -- the original CMUCL widetag and lowtag values are defined as a feature of the type system in CMUCL.

As an implementation of Common Lisp the Language, 2nd Edition (CLtL2) CMUCL -- as well as SBCL, and the small number of Common Lisp implementations in addition to SBCL and CMUCL --  essentially, every CLtL2 implementations has produced, in each distinct species of CLtL2 implementation, a manner of a semantic approach in implementing the system of data types developed and standardized in in CLtL2. Focusing on the CMUCL implementation, the semantics of the implementation might be observed as around the CTypes system developed in CMUCL, furthermore as with regards to definitions of data types and functionally mechanical forms, such as developed in the CMUCL compiler.

The CMUCL compiler's system of type definitions -- insofar as inherited by SBCL, if not furthermore adapted in the forked codebse -- the compiler's system of type definitions described, specifically with regards to SBCL, in an article by Paul Khuong: Hacking SSE Intrinsics (Part 1) (2009) with something of a reprise, in the article How to Define New Intrinsics in SBCL (2014).  The former of the two articles presents something of functional view of the compiler's types system, extending of an extension of the types system for an implementation of the Intel SSE instruction set, in SBCL.

With regards to documenting the implementation in SBCL, certainly, each functional form -- that is to say, each function and macro -- and each data value, as illustrated in either of the two articles, could be more comprehensively described with, of each, a single reference page. Each reference page could be referenced, furthermore, from a  broader documentation as to describe any manners of semantic correlations among the respective forms, in the implementation of the compiler specifically in SBCL. Although that would surely make for an interesting study, it would present a broad diversion from the topical focus of this article at DSP42.

In regards to the compiler implementation in CMUCL, and furthermore in SBCL, both implementations each define a set of data types, such that may be applied in a manner essentially internal to the compiler of each of the two implementations. Those data types may be observed for their definition and application, as around the widetag and lowtag values defined in each implementation. 

Defining a small subset of the complete set of widetag and lowtag values -- the latter, as would be defined in any single revision of each of CMUCL and SBCL -- essentially, a subset of widetag and lowtag values may be defined, such that the subset would denote the set of widetag and lowtag values defined for "User visible" data types -- i.e. a set of data types, such that might be reasonably expected as to be encountered of data values in portable user programs extending of the respective implementation. This article will denote that subset as it representing a set of types of user object.

That subset of widetag and lowtag values may then be applied such that -- for any single such type of user object -- firstly, the widetag value then secondly the lowtag value may each serve as an effective key value onto a single data storage table, such that the format of the respective data storage table may be of a format conducive to encoding and decoding of objects of such type, in a manner of a data serialization model.  Such data serialization model may be implemented as to develop an ad hoc encoding directly onto files, or as to develop a set of table structures and procedural forms in utilizing an existing database management system, essentially as for purposes of data serialization from within any single instance of the respective Common Lisp implementation.

In regards to serialization of structure objects, condition types, and standard classes furthermore, each respective type's class OID may serve as a fundamental key reference -- eliding, momentarily, concerns as with regards to  class names -- in a model then allowing for a manner of selection as to which slot values of any single class would be serialized into persistent storage, and which slot values may be initialized simply in interpretation of persistent data.

Of course, this does not describe all of the details of an object persistence model. Though it may serve to provide something of a guiding concept with regards to a deign, as such, onto either or both of CMUCL and SBCL -- not a furthermore portable design, immediately -- there may be some additional concerns that may be addressed, as with regards to:
persistent "linking" of each initialized objects to the object's persisted formfurthermore with regards to making references to objects' serialized forms without preventing garbage collection of objects that would be otherwise unreferencedand thirdly, deallocation of storage blocks on garbage collection of previously persisted objects. In albeit a naive sense, perhaps it might be more efficient to develop a memory mapped file model for the SBCL object system, such that -- in so many memory-mapped file/data areas -- an underlying operating system would immediately store any changes in the respective memory-mapped file/data areas, such that the updated data area might late be reinitialized of its filesystem mirror. This may serve to allow for something of a manner of failover, in a naive sense. With regards to optimization in the underlying file mirror, perhaps it might behoove such a software design, however, to make reference towards methods of filesystem journaling, such as with regards to the copy-on-write methodology  implemented in UFS journaling on FreeBSD.  In such regards, perhaps a broader goal may be defined as to develop a Common Lisp systems model extending immediately of FreeBSD.

In regards to the data persistence model denoted in the previous outline, certainly a consideration for the design of such a model is likewise reflected in the previous design discussion as with regards to the table group structures for the {S,P,O} data type.

Not as though to try to make such a project idea to seem too specifically grant-friendly, the prospective instance of a Common Lisp on FreeBSD systems model may be applied as for purposes of knowledge representation and knowledge sharing, effectively in any normative context to which an RDF graph may be developed -- ostensibly, even as to present a graph type model of operating system resources, such as mandatory access controls (MAC), on any single host or network, thus as to develop a management layer onto FreeBSD MAC data types -- whether or not, alternately, in as to develop any single, ostensibly peer-reviewed semantic model of the material sciences, or manufacturing, or commerce, for transparent application in communications and infrastructure support systems, at any single scale of support for material activities of a society or smaller community.

Not as though to paint with any too broad a brush, simply the very nature of knowledge modeling and knowledge sharing may be, likewise, of the very nature of the sciences. The material sciences being, furthermore, to the very essence of material technology, thence to the nature of material industry, thence to manners of material commerce, it may be possible to support development in all of industry and commerce, in supporting simply a development of science and technology in any single manner of normative social environment. 

Of course, in this broad view, a concept of intellectual property does not take up any clear or obvious place, neither any concepts of data assurance.

Ed. Note. The following section of the article was begun before the article diverged towards a more comprehensively CMUCL-like encoding for data values.

As with regards to a question of application, How many table groups like fig 6. or fig. 8 may need to be created, in any single application? and a further question, How may of each such table group may be most effectively stored and accessed for reference, in an application?  Considering some of the semantic qualities of RDF Schemas, as with regards to definitions of RDF classes and RDF properties, moreover considering the Web Ontology Language (OWL) as a specialization of RDF extending the essential class/property model, moreover with OWL adding a distinct Individual resource type to the abstract RDF data space, it may be feasible to implement a table group as illustrated in fig. 6, such that a single table group would be defined for every expressly defined OWL Class, likewise for each of OWL:Class and RDF:Class, as to provide an index of instances of the respective class. This naive "Table group per class" methodology may be further refined, if towards any singular application, as with regards to concerns of subsumption relations in RDF schema and other orthogonal considerations.

In something of a meta-semantic sense, considering the broad question of how many of a table group — as illustrated in fig. 6 or fig. 8 — may be "Well implemented," in an application, logically the question may be considered as in juxtapositoon to an orthogonal question: To what manner of a context may any such table group "need to be" singularly initialized and referenced, as a representation of any single table of {S,P,O}?

Offhand, a number of contexts may be defined — certainly, in no manner of a logically exhaustive list — in presenting at least a naive response to such a question:

Application as container of graph data sets
Graph data set as container of tuple or trie references, such as of all references of a format {S, P, O} within any single graph data set
• A Class A as a class reference context for tabular indexes of instances of Class A
• A Class B as a type reference context, for tabular indexes of instances of Class B and C, for C being a subclass of B

In this naive model, a class or type reference context may be defined for each RDF, RDFS, or OWL class both defined and being applied in any single graph data set, in any single application.

A class or type reference context need not be assigned as though exclusively to each single class. The symbolic name of a class — as in reference to cl:class-name, a function portably returning a symbol type value — as a symbol type of object, a class' name may be applied likewise as an associative reference, unique in any single table of graph-local and/or application-local data tables.

[RDF Schema] develops a type system for RDF Literal values, essentially in extending of XML Schema Datatypes.

In a model for interpretation of RDF data sets in Common Lisp, each XML Schema Datatype may be intepreted as to derive a corresponding data type in Common Lisp, together with a function for each of marshalling and unmarshalling an object of each respective type onto a character stream. Such an implementation, in a functuional regards, may resemble the CMUCL Ctypes model.

Depending on the characteristics of a Common Lisp encoding such that may be defined for any single RDF Literal data type, it may be advisable to consider revising the table group illustrated in fig. 6 or fig. 8, such as to allow for a specialized encoding in O onto {S, P, O}.

Of course, in a uniquely table stored model such as of an SQL database, then for each tabular reference as in fig. 6 or fig. 8, It may be advisable to encode a value representative of a type identity — such as of a class name, or an implelemtation-specific albeit non-portable value such as a classoid, in CMUCL or SBCL, such that may be applied as a symbolic reference to any type definition data provided of or in relation to any single class definition. A class identity, simply, may be applied for purpose of table selection in row index dereferenfcing, such as in any manner of a revision of the table set model denoted in each of fig. 6 and fig. 8.

This article essentially begins to describe a model for an implementation of a data persistence model, broadly, for objects of any arbitrary number of types, inasmuch as may be applied in {S,P,O} references in any arbitrary application. Towards developing an example onto a literary domain, this model may be furthermore developed as for purpose of maintaining a graph formatted registry of bibliographical ínformation structures, such that may be furthermore applied as in an independent bibliográphical management application within an academic content development system, or applied as an integrated feature of a graph-oriented information modeling platform — in the latter, as for purpose of creation and editing of bibliographical annotations onto graph object references, as to provide a framework for peer review of assertions in graph models.

Separating Historic Culture and Contemporary Science - Cold War Theory in a Communications Text - viz a viz Contemporary Semantics

As corresponding with a study of principles and mathematical models about the electrical sciences -- such that, candidly, I would qualify as it being a really rudimentary study, however guided of a certain, for-profit online university -- I've begun reading a text that presents some fundamental principles of information sciences, namely, The Mathematical Theory of Communication [Kindle][Open Library]. The text is principally by Claude Shannon, with an introduction by Warren Weaver, titled Recent Contributions to the Mathematical Theory of Communication. The text was published in 1963, and unfortunately there is quite a historically dated reference in the Weaver's own introduction.

The DSP42 web log will not presently diverge as though to develop any manner of any ad hoc or either, literally referenced thesis into the political domain -- such as with regards to concepts of national identities, national defense services, or fissile nuclear arsenals. If there must be any such semantic model developed or a thesis of such principally worrisome topis, it may certainly be as well if to include, in such a thesis, a study of the moral and ethical dilemmas faced by the scientists whom originally developed the nuclear sciences into weaponized applications, in the Manhattan Project. It might also be as well if to include, in such thesis, at least a slight reference to the moral, ethical, and psychological circumstances faced by military personnel, specifically around so many policies of nuclear deterrence as had, in any ways, effectively driven the Cold War. The very thought of rehearsing for Armageddon -- it might be as well if such rehearsals could go entirely out of vogue, along with the end of the Cold War.

Though perhaps it might seem as if such topics may all present a novel "Edge" to any manner of a literary interest, it might seem as if such "Edge" merely invites a puerile attention to literature.  The DSP42 web log will not endeavor to present any oversimplifications of any of the political, social, and individually ethical concerns faced by persons in  the major societies of the Cold War -- principally, in albeit an ad hoc summary, that including at least societies of the United States, Russia, and China -- and other world societies not having served as immediate actors in the Cold War.  The topic itself, with regrets, is introduced -- even if in a subtle regards -- in a  text about information science, as denoted previously. Surely, the development of communications technologies, even during the era of the Cold War, has not ever been driven as if exclusively of national intelligence services or the broader national policies and politics of Nuclear Deterrence.

The presence of a note about the cultures of the Cold War, in a text principally about information science, perhaps it invites only a difficult theoretical sidebar. Perhaps Mr. Warren Weaver may have simply wanted to make a metaphor out of the political climate of the times, in referencing concepts of "The Russian" and "Propaganda" in a text principally about communications. Perhaps that could be as well if it would be denoted to a domain of artistic aesthetics, a philosophical domain that Weaver likewise denotes in the introductory text.

It may be furthermore unfortunate that the historic, cultural, and political connotations of such concepts might likewise present a thorough distraction to other fundamental concepts presented in the same text, some of which concepts may bear a marked relevance to contemporary theories and cultures. For instance, Weaver describes three views of communications systems, as in regards to each of  technical, semantic, and effectiveness models about communications, in the same text.

The concept of communications effectiveness, certainly, may entail a sort of an operational analysis, such that may entirely diverge away from any scientifically logical model of communications. Philosophically, an effectiveness view might be subsumed by a semantic view, if the whole thing does not takes on an entirely odd angle, for Weaver's introducing the nightmarish circumstances of the Cold War.

Towards -- singularly -- theoretical concepts of technical and semantic views of communications, thereof the text finds a contemporary relevance -- such that could as well be addressed not only of concerns about national communications data monitoring as in a form of national bulk data collection, but furthermore, concepts of ontology. Likewise, a concept of national defense should be described of such a semantics, however such concepts have been developed of any social institutions.  In no ways does it depart from the domain of "Difficult topics," even if the text's reference to the political theory of the Cold War is wholly outdated, today.

Perhaps it might seem thoroughly ineffective, if the DSP42 web log was to present such concepts -- at any depth -- but would not present any manner of a technically meaningful conclusion. This article itself, clearly, has not developed any illustration of how a federal institution's data collection practices are reflective, essentially, of older concepts of national intelligence. Neither has this article well raised any ethical question to such practices, as to how some of a news from a single person's data piracy event may seem to suggest as though a national intelligence was being altogether run by machines, if the news of the "leaked" pirated data is to be trusted, whatsoever, whether for the bias of the reporting about the "leaked" pirated data, or the bias of the person whom pirated the data, or any other manner of bias, information content, interpretation, meaning, or mere entropic drift under the sun.

Though perhaps it might serve well towards a broader sense of information theory, if any of such concepts may be any more well developed to a thesis, but such concepts may likewise be distinctly difficult to develop. For all of the social and political tensions gathered about the whole entangled mirk and mire of whatever Edward Snowden's pirated "Leaks" had been selected as though to suggest, perhaps the whole thing may indeed stink of a conspiracy theory, but perhaps it may be no more than of a conspiratorial concept developed by the data pirate himself, muddying so many essential concerns of national security and personal privacy. Those concepts, likewise, could as well be addressed before any manner of discussion of any semantic models erstwhile developed, or any discussion of how it may entail a counterterrorism practice by a federal institution, or any criticism of a "Just press play" model of communications analysis.

Difficult concepts, but -- in the opinion of the author of this article at DSP42 -- the last concept in that short list, or rather a sense of personal engagement as perhaps not obviously reflected of it, that is where it may begin to "Be fun," in any humane regards, at least when it is not "Being war."

Communications, surely, may be a broad topic, among all things under the sun.

If anyone may presume of how any agency may ever go forward in any normative manner, as though to support emergent success in development of positive relations with and across communities in otherwise war-torn crisis areas, of course such a theory may seem entirely orthogonal to the previous text. There might not be so much to say about about microblogs, in contrast, however much of communications, communities, and positive humanitarian developments even in crisis areas.

Tuesday, July 14, 2015

Towards Building a Square Desktop OS - FreeBSD on the CORVID PC

Towards developing a model for graphical desktop applications on a FreeBSD operating system, proceeding in a manner by in large independent of any single, existing project, as such -- e.g. such as PC-BSD,  a distribution of the FreeBSD base system, with distribution-specific extensions, catered towards desktop computing -- simply, in beginning with the FreeBSD base system, I've been focusing on developing at least a single  "Known good" configuration.  Before proceeding to describe such configuration, some disclaimers may be in order.

This is not as though to make any manner of a radical response to the emergence of Linux distributions, in any of mobile, desktop, and network service computing platforms. Neither is it as though to try to "Steal thunder" from any of the commercial institutions developing, each, their own proprietary operating systems -- such as Microsoft and Oracle, inasmuch as Oracle had acquired Sun Microsystems, thereby acquiring commercial  distribution rights for the Solaris operating system. Simply, it's of my own small effort towards extending of any body of existing work, ultimately towards developing any new software products, in developing a multi-platform desktop computing framework out of the FreeBSD base system.

In developing my first FreeBSD desktop installation, which I'm applying in , writing this article, I'd begun with FreeBSD 10.1-RELEASE, installing the operating system from the UEFI-enabled DVD distribution. The laptop to which I've now installed FreeBSD, it's an HP Pavilion x360 notebook -- with touchscreen. The same notebook uses a UEFI firmware stack, and so of course its internal hard disk drive is formatted according to the GPT disk format.

The installation was made not without some initial difficulty. It being a dual-boot installation -- my wishing to retain the Microsoft Windows 8.1 Operating System (OS) in its installation as created by the Original Equipment Manufacturer (OEM) and later updated of my own application installation and system configuration efforts -- so, previous to the FreeBSD installation, I'd used Raxco PerfectDisk in its boot-time and normal disk defragmentation modes. After some small effort, I was able to create enough deallocated free space on the laptop's internal hard disk drive, sufficient to resize the NTFS partition, thus creating a disk space in which I could install FreeBSD. Although the Microsoft Windows 8.1 system information utilities had reported that there was a substantial amount of free space avalable on that same NTFS partition, initially, but -- perhaps, ironically -- something among the OS kernel and/or userspace applications was persistently writing a small number of file data blocks at the very end of the NTFS partition. That made it more or less impossible to install a secondary operating system.

The Microsoft Windows 8.1 built-in defragmenter was not sufficient for moving those file data blocks into any space nearer to the beginning of the partition. With a small further effort, however, I was able to apply Raxco PerfectDisk. then the Microsoft Windows system management console, to gradually create a filesystem area of approximately 175 GB of deallocated disk space. 

After rebooting, then making some small changes in the BIOS-like configuration screen on the laptop -- there, enabling legacy BIOS mode, and also enabling the processor's virtualization features, for later application with regards to QEMU and VirtualBox -- thus, I prepared the laptop for UEFI boot to FreeBSD.

I booted the PC, initially, from the FreeBSD installer DVD. I created a FreeBSD root UFS filesystem and a FreeBSD swap partition, the latter having approximately one gigabyte more of data storage space, juxtaposed to the laptop's installed RAM, to a total of approximately 9 GB swap, approximately 168 GB UFS filesystem, all FreeBSD format.

Following the installation, I rebooted the PC. On the HP Pavilion PCs, the  "Esc" key is the "Hotkey" for activating the legacy BIOS menu during Power-On System Test (POST).  Although the FreeBSD UEFI configuration on my notebook requires a manual input at boot time -- namely as in order  to select the FreeBSD UEFI bootloader, presently the second bootloader listed in the "Legacy" boot menu -- that small mater does not seem to be any sort of a notable inconvenience, to me.

Thus, after the installation, the PC made its "first boot" to FreeBSD.  Subsequently, I installed the BASH and BASH Completions packages and changed the root user's shell to BASH. Then, I added a non-root user -- UID 1000, towards a convention for non-system user IDs, as applied similarly throughout Debian operating system distributions. I then used 'scp' to copy my default screenrc, bashrc, BASH profile, and bash_logout "Dot" scripts from my LAN gateway onto the notebook, under the non-root user's home directory. Then as the root superuser, I made symbolic links to those files, from under the root user's home directory. Thus, I had installed a baseline terminal environment. I've since installed a small number of additional utilities -- mmv, uemacs, and xstow -- largely for sake of convenience at the shell command line.

Separately, I've installed a small number of developer tools -- initially, Git, SVN, the SVN2Git bridge, and CVSPS. My being by in large comfortable with the Emacs text editor, I've also installed Emacs 24. I should be updating my dot-emacs directory from my own LAN-local Git repositories, shortly. These packages, in particular, I would denote as their being elements of a developer's profile for the FreeBSD PC.

Following that, I've installed, Xinit, a desktop manager (SLIM), a desktop environment (MATE) and a web browser (Firefox, though I'd tried out Chrome and Opera on FreeBSD initially). The installation of the desktop environment, itself, also entailed an installation of a terminal emulator, a calculator, a text editor, a file manager, and some other relatively lightweight utilities.

Of course, throughout this process -- even as soon as installing BASH -- I've had to make some small configuration changes on the host, manually -- such as for some various changes onto /etc/rc.conf, /etc/sysctl.conf, /etc/fstab, and even /etc/udevfs.conf. such as in regards to SHM support for some of Firefox's HTML5 functionality, and in regards to dependencies on fdescfs, dbus services, pty services, etc.

In the process of trying out the Opera browser on FreeBSD -- namely, at Opera version 16, in its present release, as published via the FreeBSD baseline package repository -- I'd also installed the Linux C6 32 bit emulation for FreeBSD.  Subsequently, I'd tried to run Opera version 30 in its Linux (amd64) edition -- then, subsequently, a 32 bit distribution of Opera Version 30 for Linux. Though I think it was quite nice to see that there is a 32 bit version of Opera 30 available, for Linux platforms, but -- insofar as concerning the Linux emulation for FreeBSD -- Opera 30 requires some features that, apparently, are not as yet ported into the Linux C6 32 bit emulation for FreeBSD. My being more immediately concerned as to install a usable web browser to the PC, I've installed Firefox, with no subsequent issues.

Presently, on having observed a note towards possibly developing a FreeBSD edition of Firefox OS, I might wish to wonder what specific licensing concerns there could be for redistribution of the nspluginwrapper port. Reviewing Section 7.2 of the FreeBSD Handbook, apparently there's a concern with regards to redistribution of compiled binary versions of the nspluginwrapper port. Towards a transitive concern with regards to Adobe Flash applications, perhaps a project may need to curry the favor of Adobe, itself, if to ensure that an Adobe Flash plugin might be developed for any single web browser on FreeBSD, or perhaps the SWFdec plugin could be more further supported as a third party plugin for Adobe Flash applications. Referring again to the FreeBSD Handbook, it may seem that those are the two primary alternatives available for Flash support in a web browser on FreeBSD. Perhaps, that may serve to present a concern as towards any possibility of applying a Mozilla Gecko application stack for user interactions with regards to web applications, on any manner of a FreeBSD distribution of Firefox OS.

Alternately, in a figurative sense, perhaps one might endeavor to chart a course towards the furthest side of the furthest known minor planet, Pluto, as if there to develop a by-in-large distinct web application framework onto FreeBSD, with minimal local distractions. Perhaps at such a destination, one may propose to apply Steel Bank Common Lisp (SBCL) -- for instance, in focusing about SBCL's compiler optimizations, among other portable ANSI Common Lisp implementations -- and a fork of each of CLORB and McCLIM -- of the latter, focusing on the CLX CLIM Port, in McCLIM.

The same platform could apply the upstream CLX codebase, unforked. Alternately, in any project developing such a platform, the project might endeavor to develop an implementation of the MIT shared memory extension (MIT-SHM) as perhaps towards any more of an ideal sense of efficiency in "Same-host" CLX client applications on X Window servers likewise supporting the MIT-SHM extension. Perhaps it might serve as to minimize data transfers over local socket channels for X Pixmaps, at least, if MIT-SHM may be supported in CLX. Around such a development, perhaps it might be apropos also to develop a memory locking framework for SBCL, such as to prevent password data or other sensitive user data fields from being paged out to disk from within an SBCL runtime process.

Both of the MIT-SHM and the "Unpaged RAM" features would entail something of a matter of -- if a reader may pardon the pun -- addressing memory areas in the SBCL data space. Of course, the  MIT-SHM extension might also require an integration directly with C-format XLib libraries -- thus, perhaps creating an awkward situation in which a non-C-language XLib implementation would use only a small modular part of a C-language XLib implementation. however therefore depending on more features of the C-language XLib implementation, so far as functionally depended-on by the single shared module.

The "Unpaged RAM" extension for SBCL would not require any dependencies expressly onto any additional toolkits. As well as with regards to user data security, the "Unpaged RAM" extension might be furthermore applied for purpose of deterministic scheduling in a realtime computing model applying SBCL.

Personally, I've considered reviewing the Enlightment Foundation Libraries (EFL) separately, for such an albeit unlikely project.  EFL is licensed under BSD style licensing terms. As an application toolkit, EFL moreover publishes a C interface. Although the Enlightenment DR17 window manager, itself, might be somehow difficult  to configure for some FreeBSD PC environments, but perhaps it could al work out better on mobile. EFL is used in the Samsung Tizen platform, after all. There's also EFL WebKit  -- there, to yet another concern with regards to web browsers ostensibly on FreeBSD, furthermore towards some more of a concern with regards to toolchains. EFL WebKit uses CMake.

The author is not immediately certain if any of this would be any easier to "Parse" if it was all formatted in a succinct RDF graph, instead. Perhaps it might seem "Too easy," in such succinct rendition.

Monday, July 13, 2015

Towards an RDF Encoding for the IANA Language Subtags Registry for Presentation in Graph Views and Application Data Spaces

While I was reading some of the existing documentation about the Resource Description Framework (RDF), last week, I found myself wondering about a particular feature with regards to localization (L10N) -- in a broader sense, internationalization (I18N) -- namely as with regards to internationalization of static application data label text, moreover as concerning a concept semantically towards an application of CORBA in Common Lisp, at an extent that the implementation might be integrated more thoroughly with the Common Lisp Metaobject Protocol (MOP), more than the present Lisp bindings for IDL. 

Hypothetically -- in an offhand design specification, albeit -- an IDL implementation may be defined, effectively, as an extension of MOP. In an application view, IDL attributes may be represented with specific extensions of the MOP slot definition classes, such that the extending classes may naturally serve as to encode features of IDL source forms, secondly such that may be applied in reflective procedures of a CORBA Interface Repository (IR) in defining, essentially, both of an abstract application space, via portable CORBA object services, along with an application serving as an implementation of the same abstract application space in portable Common Lisp. The concept of an abstract application space, as such -- though I might be the first person ever suggesting any such concept -- I think it's almost suggested by the design of the application space of the Android platform, together with any number of web service applications such that provide data services for Android applications. Though it might seem to be as if written between the rows and columns of application icons on an Android home screen, moreover hinted towards -- ever so subtly -- via the Android resource 'share' feature, buy insofar as if such a thing would be assembled exclusively of HTTP services, I'm afraid it might make for something of an overall protocol nightmare, candidly. 

Although it may seem as though the set of extensions of the primary CORBA specifications have been defined, by in large, for support of enterprise commercial systems, and -- in something of a sense of nuance, perhaps -- it might be assumed as though there was no space for any sort of an independent platform in CORBA object services, and -- if one would suggest otherwise -- it might seem like all of an absurdly radical concept, there's my primary concern in denoting any such concept.

Presently, the discussion will resume to a matter of language codes.

After some litttle tooling around with the Protégé toolkit, of course the author is familiar with the RDF syntax of suffixing a language tag to an RDF literal resource, such as to denote a logical, linguistic derivative of a fundamental resource concept, or directly to denote a language in which an RDF literal value finds a lexicon. RDF language tags might find their broadest use -- broadly -- as object values in RDF annotation properties. I can't say as if that's been written so clearly in any specific documentation -- I don't believe I've ever read such a thing, precisely anywhere. So, perhaps it's simply an intuitive observation.

So far as regarding the syntax and structures of language codes as may be applied in RDF literal values, certainly one may endeavor to consult the documentation. In reading a few resources about RDF schema, as such -- long bibliography written short -- I noticed a reference to IETF BCP 47 -- in a sense, however indirectly, updated with RFC 5646, RFC 4647, and RFC 5645.

BCP 47, oringinally makes reference to an IANA Language Tags registry, which in turn makes reference to the IANA Language Subtags registry. To my best understanding, the latter serves as something of a formal structured reference, by in large supplemental to sets of language codes and script codes published by the ISO — in the latter regards, concerning script codes, thereof in manner orthogonal to Unocode Code Sets. Considering the structures defined of the IANA language subtags registry, perhaps the same regsitry may itself serve to provide something of a sense of linguistic semantic knowledge, more than the ISO language codes unardorned. In a sense, the IANA Language Subtags Registry serves as to collate so many language and script identifiers such that are defined, originally, in ISO standards documents. Of course, the IANA Language Subtags registry does not go to any great detail in its data record values, as to the providence of each respective language code or script code. However, the  providence of the data values is described — broadly — in documents published of the Internet Engineering Task Force (IETF).

Orthogonally, considering that the Language Subtags registry does not make reference expressly to the Sorani or Kurmanji dialects of  Kurdish languages -- rather, delegating the Kurdish languages to a total of three geographical subsets of no specific cultural characteristics, apparently in extending of ISO 639-3 as such [Wikipedia] — not to permit the ISO specification as though to remove any language of its characteristic pith, a secondary reference may serve to describe any qualities of broader cultural meanings, to which the three odd geographic definitions of Kurdish languages [Kurdish Project] may be supplemental.

Of course, if all language was so tidy as to be fit easily into a neat ontology,  that would certainly serve to make a librarians' tasks altogether easier. However, if all language was all so far standardized as to meet the specifications of any single institution's own views of language, it might furthermore serve to remove all of a sense of organic, expressive wit from the nature of language itself. In so much as denoting that there are normative string values by which any single work of an expressive text may be annotated for its language, I believe it is not as though to suggest as if any single language tags model, itself, could ever serve to define all of any language, however a language tags model may ever be applied .  In a simplest sense, perhaps a system of language tags  may serve in a bibliographical role, perhaps in a manner secondary to any applications of language tags for a purpose of user comfort and user convenience, in a service for networked content negotiation -- such as in HTTP.

In so many things, a model may not exclusively define any object that a  model may soever deign to describe. Much like languages, models are imperfect artifacts, never completely describing every functional detail of any system beyond a form of a model, itself. Inasmuch as that a model may serve as to convey a useful range of concepts and specifications, however — leaving aside any reflective analysis of any specific semantics in modeling — but as in that a model may serve as to communicate a useful set of concepts, in any of a manner essentially independent of media, thereof a model might find at least a manner of a utility role. Essentially, a model serves as a communicative document.

Language being a broad concept -- furthermore, a concept ever evolving in parallel with any contemporary social trends or discrete styles in developments and expressions of language -- certainly, as even that a momentary language tags model may ever serve in a sort of utility role, in establishing a sense of idenity about a language, in communications, but certainly a language tag in itself may never be all of a language.  Even insofar as of the English language, clearly a popular language in contemporary communications, there are some literary forms that essentially disregard the limits of classification and identity of language. The poetry of Amiri Baraka occurs to the author's own literary consideration, as such. Historically of European cultures moreover, the concrete poems of Kurt Schwitters — aside to the Dadaists' own original sporting about identities in the arts and society, the Dadaists more or less creating a new manner of expressive absurdity, shortly past the end of WWI, perhaps in a time too early for the Dadaists to be categorized to a Postmodernist school, though one might endeavor to estimate, intiitively, that the Dadists were some of the modern society's first postmodernists, in a manner of an ad hoc thesis, albeit — simply, the concrete poetry developed by Kurt Schwitters would deny any single linguistic classification. Although it finds a literal form in a Latin script, as per any single written publication — historically, publications as made astride to the events of the small number of Dada Soirees in Europe — it may be likewise an original language, although scarcely known and scarcely adopted, but a language expressly developed by Kurt Schwitters, otherwise unknown of its ownership and identity, to all the pages of archival history. If one may suggest a style in homage to the Dadas' own post-consumerist works, unabashed of the nearly infantile syllabery of the original concrete poems, perhaps it was the language of Schwittersian European Regression Inc. Considering the Dadaists' own efforts in reconciling a critical wit to a commercial modernity after the long effects of the First World War, as a concept, perhaps it may serve to suggest that there is a heritage of empathy, in the works of which the contemporary artistic postmodernity has evolved.

That grain of salt now idiomatically aside: The IANA Language Subtags registry -- in all of its broad, structural form -- perhaps, it may be one of a markedly significant number of resources such that we, as people, may not too quickly dispose of. However it may be that the Language Tags registry, itself,  became denoted as an "Obsolete" resource — in any analysis of events over time — but in considering the structural nature of the Language Subtags registry as it representing at least a best effort for defining structures of languages -- at least, insofar as for applications in regards to representation of text in electronic media -- certainly, the structural nature of the Language Subtags registry may not be, in itself, so far outdated.

Thus, although the RDF specification -- even insofar as its rendition in the ODM 1.1 Metamodel [ODM 1.1] -- may denote only a string syntax for representation of language tags, the author believes that it may be well to define a broader CORBA model, to an effect, a Language interface definition. The IANA Language Subtags registry may, itself, serve to provide a sense of structure for an initial Language interface implementation, such that may applied within a CORBA application system, if not in a definition of a broader, abstract application space.  The author having no broad manner of an academic reputation with which to present such a thesis, however, the author contrives to present it if only as a "Belief," that a structural identity for Language may be apropos, as a feature towards — broadly — a definition of an abstract application communications environment, such as may serve to implement a singular service mix as may extend of existing CORBA object service definitions, augmenting the latter so as to define a complete networked application environment of CORBA object services, essentially as communication services, moreover integrarting a set of broader network application services — such as Kerberos authentication services and transport layer security models — as to define a comprehensive model for trusted digital communications, ensuring of nonrepudiation and neither neglecting of creators' rights, in defining an abstract CORBA application space, irrespective of individual machine architectures. If, hypothetically, a CORBA application service model may be furthermore applied in support of any formal, civil disaster relief and emergency services operations — if not furthermore, applied in roles for knowledge discovery, as with regards to literal, audio, and visual media — then perhaps it may moreover stand as to remove much of a figrative bight, in altogether a positive regards, concerning some communications about application service architectures. Certainly, CORBA may be applied towards portable definitons of network service models in civil service applications, inasmuch as CORBA services have ever been defined for applications in national defense systems, and such applications — though not any details of any platform-unique CORBA application services, direclty — then discussed in an open forum. The author of this article, on having read of such defense-oriented applications for CORBA, is simultaneously impressed and nonplussed of such news. It may seem as if to suggest an altogether awkward style for communications about an otherwise benign object service specification. Moreover, the author does not believe it could be either useful or necessary to "Refactor CORBA" — though such and idea might occur — as whether or not if to address any vaguely sympathetic sense of concern about any existing, platform-unique CORBA object service definitions anywhere in controlled media.

So far as to propose any exact structure for a Language interface, of course there are the semantic characteristics of the IANA Language Subtags registry, and the structures of ISO 639 specifications dash 1, 2, and 3. Wikpedia, furthermore, denotes a singular manner of linked open data resource, namely Glottolog -- in reference to any apparent conventions in denoting dialects of Kurdish languages [Glottolog] -- such that the author makes reference to, only with a further note: Candidly, to the author's own understanding, not all persons might appreciate a categorization of Kurdish languages as if all of Kurdish language was subsumed under a category denoting Iran. Certainly, in considering it as a semantically if not historically framed categorization, certainly it might not have been defined as if to suggest any manner of a political interpretation. In a contemporary sense, perhaps it might not be so easy to interpret, as in some points of view with regards to any manners of contemporary political and social institutions in Southwest Asia. Concerning Kurdistan's representation in contemporary Iran, as well as to Kurdistan's representation in contemporary Iraq, contemporary Syria, contemporary Turkey, and abroad to the Middle East, such as in the EU and in the US, certainly a people's geographical distribution may not serve as though to permit so much of an easy geographic categorization, if in any regards — as if secondly — to characteristics of language.

Thus, perhaps the author might begin to understand if there may be any difficulties faced by linguists, in reconciling even a simple, however common language annotation tag to a language form.

Insofar as that a programmatic Language interface may be defined as in a generic manner of definition, as though irrespective of any specificstructures of individual language code registries — perhaps a generic manner of definition may serve as to permit for definitions of more semantically specialized extensions, onto individual language identity lists. Simply, a distinct Language interface may be defined — as in a CORBA application protocol, such that a Language interface may be defined originally in IDL — such as to replace the optional "Language string" of an RDF Literal resource.

In any later definitions of application protocols, the Language interface may be furthermore applied as in a session-oriented definition of locale identities for purpose of data field localization, in a manner essentially abstracting POSIX LC_FUM environment variables. Orthogonally, POSIX shell environment variables may be represented in an abstract model, altogether, as session variables, such as towards a definition of a CORBA model for ad hoc shell command interactions, whether via TTY, PTY, or Ethernet networked data channel. POSIX, as a brand name, is certainly a trademark of its respective trademark owner.

Concerning the RFC 5646 definition of the  IANA Language Subtags registry [RFC 5646], RFC 5646 section 3.1.3 describes seven classes of record for entries in the registry [list misformatted by Blogaway app, in edit, reformatted manually]:

In the data records of the IANA Language Subtags registry, each language type record is denoted with a corresponding subtag value, the syntax of which may serve to indicate the origins and applications of the subtag value. As denoted in RFC 5646 section 2.2.1., two-character subtag values are derived of ISO 639-1. Three-character subtag values -- excluding any subtag values as may occur in the lexical value space, in range [qaa - qtz]-- other literal three-character subtag values, as defined in the registry, are derived of an effective set union of language codes in the ISO 639-2, ISO 639-3, and ISO 639-5 specifications.

Although the IANA Language Subtags registry provides a textual name for each language entry -- namely, in each record's description field -- however, for purpose of internationalization in presentational applications, it may be preferred that a language definition would make reference to records encoded in representation of each of the respective ISO source documents. In some encodings of the ISO 639 language codes, for instance, there may be localized strings available, for representing each respective langauge name in a lexicon of any single language..

Concerning the instances of single language records having multiple description fields, in the Language Subtags registry, perhaps an RDF encoding for the  registry may be preferred -- as towards a sense of any project developing a programmatic, graph oriented encoding of the IANA Language Subtag Registry.  Of course, an RDF encoding may serve to present a a sense of further challenge for adoption in a CORBA application service protocol. However, in translation to an RDF encoding, certainly all of the information provided in the IANA Language Subtags registry may be preserved, as across the transition to the subsequent structured record format. The RDF encoded model may be subsequently accessed via CORBA, in a model extending of ODM [ODM 1.1]

Certainly, in analysis of other than the language records in the IANA Language Subtags registry, s9me further information may be interpolated of the respective data records of the Language Subtags registry, such as in reference to RFC 5646 -- such as to determine, when possible, the data providence of each record field, furthermore to determine each tag's compatibility onto other specifications, e.g. ISO-15924 as with regards to script records.

In defining, essentialy, a knowledge model for standard language tags and other language identities, it may be noted that the language knowledge model, itself, may need not be applied in all applications as may provide any manner of localization features. Insofar as that a single application may utilize a single subset of language codes, such an application may access any one of respective subset of language codes as a session-local value, without immediately requiring an interface be provided onto an entire RDF language graph.

Of course, inasmuch as that an RDF language graph may be applied for purpose of facilitating translation of language codes, across compatible language code sets, furthermore as may support an interactive selection of language-specific resources, if not moreover to facilitate a machine translation of text or other media, an RDF language graph may serve in a supportive role, in so many interactive applications. Regardless, if an application may not itself require access to any single graph view of language identities, perhaps it may be advisable to define two distinct Language interfaces — towards one definition of a Language interface, as may serve to express a portable graph of language identities, and another interface definition as to provide a view of a language identity as a resource in a graph view of language. The latter might be of some use to students of language studies, moreover for applications in academic linguistics. The simpler, non-graph-integrated Language interface definition may serve a role for simple localization of data label strings, in any manner of interactive applications.

Towards illustrating a simple usage case, the session variables inteface deinition — suggested in the previous — may be relatively easier to illustrate, initially,  in an application providing a simple CORBA session proxy interface to a shell terminal. In such an application, the session variables inteface deinitions may be applied  in a manner that would be principally irrespective of the syntax of any individual shell environment variables — thus, without applying any manner of a specialized Language interface definition, immediately in the shell emulator/shell proxy application.

Hypothetically, a manner of a dispatching controller application — perhaps, in a manner analogous to an abstract user session manager for an abstract application space — such may be defined as to extend of the shell emulator/shell proxy application, in such a manner as that the values of the respective LC_FUM variables would be derived from session data recorded in the dispatching controller application.

Precentky, the author proposes to update the Hardpan Tech fork of CLORB, subsequently to develop a proof of concept as suggested in the previous.

Sunday, July 12, 2015

Concerning a Long Arc of "Documenting Progress" — Toward an Archaeology Minus Nihilism

This may be the first article I'll have written as to describe my own albeit naive views with regards to archaeology as an academic practice, archaeology as a rhetorical domain, and archaeology as a a concept.

It's likely to be a short article, as such. There's certainly a great lot of academic legacy that has been developed, but that I am heretofore unfamiliar with, in regards to any of those three points of view with regards to, broadly, archaeology as a concept — a concept, certainly, entailing any manner of a study of objects of historic consequence. I'm certain that there might also be a lot of connotations about a concept of archaeology, such that may be observed, whether or not moreover described, to any of a sense of relevance in any single context or contexts of metaphysical theory. To comment of my own gallow's sense of humor, but it would certainly not be apropos to the present discourse. The artifacts of ages — if simple artifacts cannot be carried across any of a great, unknown terminus, but what may endure of any of a persistent nature of knowledge?

Archaeology, as a concept, is such that I have had only some limited exposure to. I have, in fact, been on an archaeological "Dig," at once in my own life's time — an excavation, informally, of historic artifacts erstwhile discarded of earlier family, glass and metallic objects enduring the weather below the topsoil of an old discard pit, no doubt of a time before there was any regular waste disposal service, in all the durations of a western town of California, over time. Those artifacts, I understand, traced a duration in my family's own heritage, our migrations and adaptations in the United States.

It is not a point of view that I may presume to make any agendas about, my own family tree spans groves some or which grew of the First Nations in the United States. Of course, the rest of us had migrated away from the original climates of Europe, each in a distinct duration of time. Personally I have not, as yet, begun all of any formal geneaological study of my family's own migratory transitions and places of residence. I have heard mention of some serious genealogical research projects, in my family. It is such that I am wont to maintain a sense of privacy about — family heritage being, certainlymost often, such that one may not wish to make any of a grand exhibition about. Moreover, my own creative faculties have certainly been afrected for sense of style, as in study of works of simple storytelling in science fiction.

In which regards, perhaps the film Prometheus, stylistically, might seem as though to suggest aa that there may be quite a dark theme going, in much of contemporary storytellng. I am, personally, more a fan of Charles Scheffield's Heritage Universe — of which, if it will not spoil the tale to denote, the Zardalu species as antagonists in the tale, perhaps the Zardalu were of a great darkling kind of species in the evolution of the story, as mcontemporary to the books of the Heritage Universe as original works in creating a universe of a story. Surely, the Zardalu had seen better days. By the time when Hans Rebka & c. arrived, the Zardalu had become clearly a menacing species. Certainly the Zardalu had not then descended altogether into the darkness of any persistent evil, such as of the domain of — no doubt — of Dante Aligheri's own favorite antagonists, whether in or beside the old Latin book, Inferno.

Personally, perhaps I've studied more of an archaeology of storytelling itself, moreso than ever to presume as though to extrapolate of the world immediately around me. Of course, a work of storytellng may not often produce a great many artifacts. There are books and the props of theatre, never often a great commerce of the storytelling media, aside to the commerce of commercial radio, commercial television, contemporary cinema, and the broader Networks and Webs of immediate society. Aside so many commercial productions, perhaps it may seem as though an art of storytelling, itself, was merely accidental.

So far as that it may be said that there is a quality of storytelling in life, itself — perhaps, it may not permit any too trivial ontology — inasmuch as of an analogy, perhaps it might be said that a study of archaeology may draw a parallel of life, itself — however conducted in formal study and formal dissertation, how parallel to observations of artifacts and locales, how reinforced of the accumulated social narrative and scientific knowledge of which the state of the art in archaeology, itself, might ever be discovered.

Though I have ever made any of a formal study of anthropology — thereof, finding a sense as of a personal resonance with regards to an anthropological concept of participant-observer — and participated in the excavation of family's discarded artifacts — but archaeology as a formal academic concept is formally and in much "New, to me."

I've commented, in the title of this article, towards a persistent sense of nihilism, such that — to my point of view — does not ever depart from the shadow of social studies. What is "An Archaeology Minus Nihilism," therefore? Is it a concept any risking of a glib and naive positivism, or an unbalanced view of concepts of Yang as if entirely removed removed of concepts of Yin, metaphysically? It is, to my point of view, a concept daring to discard an ages old sense of pessimism as to any of the immediate and further destinations of the material cosmos, likewise daring to depart from a climate of social assumptions as to what may have conveyed humanity to wherever we are proceeding to.

As an orthogonal concept, such that I am certainly unfamiliar with in all formal regards — it seems, to me, like an emergent concept of academia, whatever its academic objectives overall — a concept of archaeology, if applied onto a very short duration of time, might be … more relevant than I can say. Whether of an observer's analysis of trends, a participant's observations of media and story, or all of a dry coroner's view of crises, it seems to me that it demands a stakehokder analysis of a scale as I am individually, singularly unable to manage.

Thus, I've begun to emphasize comunications, in works of communication. An analysis of metaphysics might be all be beyond me, for all of communications.

GraniteStor - Design Abstract - Towards Definitions of an Abstract Application Space and a Design of a System for Applications of Generic Data Resources

Beginning of an ad hoc abstraction of the Common Lisp 'load' function, the following article endeavors to develop a sense of structure and semantics of an abstract application space, as primarily towards definitions of CORBA object services for distributed computing environments.

For a program system to be able to process any number of one or more program resources -- resources such as would represent source code or compiled object data, such as would affect the runtime execution environment of the program system, on load --  a program system must first locate the program resources.

After locating a program resource -- as whether located via a kernel fileystem service or userspace application service -- the program system may  then establish a data connection to the service by which the program resource has been located. In a manner of typical file input procedures, in an instance of an operating system kernel implementing a POSIX model for system procedures -- such as Linux or FreeBSD -- the data connection establishment procedures might be represented by the program resource establishing a file descriptor onto a filesystem resource, via a C 'open' or 'fopen' function. For accessing a program resource via a compressed archive file, alternately -- such as for program resources stored within Zip format Java Archive (JAR) files -- broadly, a data connection may be established for accessing the compressed archive containing the program resource, then any one or more archival procedures may be performed such as to retrieve the individual program resource from within the same compressed archive.  In a third example, for accessing a program resource via a trusted WebDAV service, firstly a network application session may be established to the WebDAV service, then secondly a data connection may be established for accessing the individual program resource as via the network application protocol implemented by the respective WebDAV service.

Subsequent to that a data connection would be established -- as to access a media object effectively representing the contents of a program resource -- the contents of the media object would be processed to an effect of loading the program resource into the program system's program space. Lastly, the program system may endeavor to perform programmatic operations such as would have been loaded into the program system's program space, originally from the program resource.

Orthogonal to the procedures of data connection establishment and program resource loading, then -- as specifically considering an example of accessing a program resource from  within a JAR archive file -- effectively the example may serve to lend to a sense of filesystem containers. A JAR archive file, broadly, is a compressed archive file with a specific internal archive format -- more specifically, an archive file compressed with Zip compression, secondly the archive file having a specific internal filesystem format. As a special manner of archive file, a JAR archive file serves as, effectively, a filesystem container for Java program resources. Typically, a JAR archive file may be accessed by a Java Runtime Environment (JRE) as for a purpose of  load program resources -- such that those program resources would  typically have been compiled with the 'javac' compiler of a Java Development Kit (JDK). A JAR archive file, more broadly, may serve as a container of non-program data resources, such as of configuration data and static graphical interface object data.

Aside to any manners of specific, semantic differentiation of data resources -- as with regards to semantic differentiation of program data resources and non-program data resources, as in regards to structures and applications of data resources -- with an example of the JAR archive file as a singular keynote, an abstract container model may be designed for modeling of data resources. The abstract container model, however developed, may be expressed for applications in a portable, platform-agnostic format such as CORBA IDL. In applications, the abstract container model may be implemented such as for an application to provide CORBA object services onto any number of resource types, as may include: Archive files; networked application protocols providing filesystem services; filesystem directories; individual filesystems; application-defined structures such as of ASDF system definitions, Apache Maven Project Object Model (POM) definitions, or individual software package structures.

Broadly, towards a definition of CORBA Object Services for access onto filesystems, two examples may  be considered: CORBA Audio / Video services [Han2004] and DOM 3 Load and Save [DOM3LS]. In albeit a naive sense, a CORBA Audio / Video services implementation may serve to provide an number of stream-oriented multimedia playback and control services via a networked CORBA architecture.  DOM 3 Load and Save, beyond any specific applications in the document object model, may serve to provide -- broadly -- a structured, event-oriented approach for file data processing via a networked CORBA architecture. Hypothetically, any number of extensions may be developed for applications of DOM 3 Load and Save functionality, in a manner broadly orthogonal to representations of Document objects in in the Document Object Model (DOM), more specifically extending of an event-oriented data structure processing model as developed of DOM.

In a manner of narrowing a design of an abstract container model for data resources, in focusing -- broadly -- on structured formats of individual data resources: Any single file type data resource, in itself, may be modeled as a container for persistent object data, such as may be encoded within a single file data resource.

Hypothetically, an object storage filesystem may be defined, such that the object storage filesystem may store and retrieve persistent object data in a format specifically of object types and object data fields -- in a sense, focusing on storage and retrieval of object data structures such as of DOM Document objects, not expressly focusing about storage and retrieval of object data serialization structures such as files, filesystems, and file archives.

In an implementation onto an existing operating system -- inasmuch as that an object storage filesystem may be implemented onto an existing filesystem architecture -- a filesystem architecture such as may be underly an object storage filesystem may need not be -- in itself -- defined as to be expressly "Pretty printed" in any single structural list. If an object storage filesystem may present at least a human readable view of objects stored in the object filesystem -- not either in obviating concerns with regards to data access rights -- then any object data services, such as may be defined in an implementation of an object storage filesystem, may store and retrieve data onto an operating system's underlying filesystem device, using any single baseline file naming scheme and any collection of specific file formats such as may serve to allow for an efficient storage and retrieval of object structure data, in the respective object data services.

Not as though to propose to reinvent an operating system, an object data storage system in Common Lisp -- when implementing a CORBA architecture in Common Lisp -- may effectively "Borrow" the CDR encoding format implemented in CORBA IIOP. Perhaps a CDR implementation, furthermore, may be refactored for marshalling and unmarshalling of object data onto a filesystem -- juxtaposed to marshalling and unmarshalling of object data within a network peer services architecture.

So, hypothetically, a single CDR Serialization service may be defined, such that the CDR Serialization service would effectively serve as a channel encoder/decoder for object data as may be stored onto persistent media.

This is not as though to recommend that a CDR Serialization service would be applied as if to instantaneously persist data structures and values for every object initialized within a program system. Certainly, in a hypothetical embedded computing platform, the figurative tires of a serialization service might wear out a figurative NAND/NOR road, if the figurative tires would be run on the figurative road, too frequently. That is to denote, as by way of an analogy, that a memory technology device (MTD) may allow for only a limited number of store/load cycles for data stored in the MTD's NAND/NOR firmware, without degredation of the MTD's storage capacity -- aside to any nondeterministic metaphors as of road maintenance for MTD applications.

So, in designing a model for a program system suh as may implement an object data serialization service -- as may extend of a conventional filesystem service -- a distinction may be drawn between runtime data structures and persistent data structures. As one possible juxtaposition: A distinction may be defined in a sense of a failover view, such that If a set of runtime data strutures would not be recorded onto persistent media, that it would not irreversibly degrade the performance of an application, if the data structures would be effectively "lost" as due to termination of a processing thread, if not a complete system power cycle in the underlying computing platform.

In another sense of a juxtaposition of persistent and runtime data structures: A discrete set of filesystem data records may be processed by an object storage service, such that a persistent data structure may be initialized of the contents of the filesystem data records. Subsequently, the filesystem data records may be updated -- certainly, updated in a transactional regards -- updated for any changes in any corresponding data fields within the persistent data structure. A persistent data structure, in itself, might make reference to  any one or more runtime data structures, such that would not be recorded onto a persistent filesystem media, though referenced by a persistent data structure. In a description of such a view, it might furthermore be noted that an object storage service may be defined as an abstraction of table-oriented data storage models, such as may be implemented with regards to portable SQL.

In a sense with regards to storage models for tabular application record structures, perhaps the former might be juxtaposed to a more generic file-oriented data storage model, as in that a tabular storage model may serves to add any set of structures for  tabular storage of persistent data records, essentially specializing a generic persistent storage model, in the abstract application space.

Towards a further juxtaposition of runtime data and persistent data, a juxtaposition may be presented as with regards to an orthogonal concept, broadly, of how applications process data. In albeit a broad case study of a hypothetical application, Bazomatic, the Bazomatic application may store a certain selection of data values into a structured format in persistent data storage. On processing of any set of persistent data values as thusly stored, the Bazomatic application may create any discrete number of relational data values in the Bazomatic application runtime data space, as for purpose of maintaining a sense of data structure among the data values originally stored into persistent data storage. The relational data, as such, may need not be stored expressly into the persistent data files -- the relational data being represented, in an application-specific manner, as though in implicit relations among persistent data values, in the structured record format of the Bazomatic data storage model.

Beyond a view with regards to data record formats, moreover an application program may create any number of runtime data values as to represent, structurally, any specific set of qualities of system devices such as may be accessible to an application's runtime environment -- such as of individual keyboard, mouse pointer, touchscreen, LED, printer, or other input/output devices.

Of course, with regards to data presentation, an application may likewise store any relatively small number of persistent session data values, within any single computer system user's own data storage space -- such as of window positions, in an application session of a graphical windowing environment. A system user's own persistent session data may be applied within an application system, as for purposes of configuration of application session properties, across any single application session durations

In a manner more functionally fundamental than the data presentation systems of any single computing environment, a computer system may furthermore present any number of persistent data storage devices and network data communication interfaces, in a manner internal to the computing system's own runtime operating system. In regards to network data communications interfaces, orthogonally, the author wishes to make a note with regards to the Netgraph architecture implemented in FreeBSD. If the Netgraph architecture may be extended for direct access to persistent data storage devices, perhaps such extensions may furthermore make reference to the FreeBSD virtual process jails model -- as perhaps towards an altogether abstract model extending of real implementations of services for data storage and data communications, within a contemporary computing environment.

Orthogonal Concept: Offloading Filesystem Handling to Kernel/Userspace Filesystem Adapters - FUSE

An outline for any good' ol' "TL;DR" synopsis