[humanmarkup-comment] High Level Overview

[Rex Brooks <rexb@starbourne.com>]

Hi Everyone,

As I see it there are two overarching High Level issues, processing 
and viewpoint.

Processing refers to the inherent grammatical structure of the Human 
Markup Language. This is built up of elements defined by our Primary 
and Secondary Base Human Markup Language XML Schemata. By definition 
I also mean datatypes that are either defined by the individual 
elements or their attributes. These elements, which comprise the 
primaries or primitives of the language can then by combined in a 
(similarly structured?) set of RDF Schemata to produce the working 
grammar or grammatical (semantic) rules of the Human Markup Language. 
I put the parentheses and question mark in to let you know that I 
have not reached my own conclusions on that. Also, these rules for a 
working grammar must be adaptable, not hard and fast, at least in my 
opinion, and as such should be constructed in such a way to allow for 
that. This is all, of course, quite debatable.

Viewpoint refers to the standpoint/endpoint uses, of the application 
developers at the time of development, for which the language is 
meant or to which the language can be accommodated. 
Standpoint/endpoint means the paired concepts of where you are and 
where you want to go, or what the problem is and what kind of 
solution is sought. I don't know if it is possible to set these 
viewpoints before the problems or situations are clearly defined, and 
we certainly do not have a language or structure today which comes 
close to fulfilling the need. This is the emerging arena of Knowledge 
Theory, and this is where the notion of Complex Adaptive Systems and 
thence to Stratified Complexity comes into play.

In terms we understand across disciplines, this amounts to a 
considered and accommodated acknowledgement of the uncertainty 
principle which requires us to understand that we change anything 
that we observe and create blindspots at the viewpoints we occupy. 
Therefore, we must always employ mutliple observers and allow for 
adaptation of our own observations.

I am not aware of any language which begins to set forth such 
concepts, and I didn't set out to do this, but this does seem like a 
good idea to me now. However, I do not think we should allow these 
considerations to prevent us from continuing to develop the XML and 
RDF Schemata we are working toward because I suspect that the guiding 
principles from which we might build a paradigm for this approach 
will likely emerge from that work rather than be directed by the high 
level work. It may seem illogical but I really think that this is the 
only way we can proceed. We can't know beforehand, what we will learn 
(observe), but we can keep track of the questions we ask and continue 
to ask if the answers change the conditions from which those 
questions were asked.

We actually went over this approach in a slightly different way 
concerning the notion of emergence in Phase 0. However, by 
consciously running a parallel effort for consideration of these 
higher, more abstract, level issues while we work at the lower, more 
concrete, levels we can continuously hone our work.

You may notice that I haven't suggested a deliverable or set of 
deliverables for this effort. That will have to be ironed out in the 
subcommittee itself. It may also require its own mailing list.

Lastly, I have to say that the one thing we all need to improve 
across the board is framing our explanations within normal, more 
conversational lay language, rather than notations which our 
individual disciplines and long use tend to literally "burn into" our 
own neural circuitry. I am facing this problem in other TCs as I 
encounter this problem of overlapping terminology and overloaded 
vocabularies.

Ciao,
Rex
--