OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

humanmarkup message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: [humanmarkup] PBS-Change Requests


Title: PBS-Change Requests
Hi Everyone,

I am about to give you examples of the two kinds of Changes Requests we can make at this point in the procedure in which we are engaged.

First, although I am about to indulge in what might seem like a paradox, giving you a quite long sample of the kind of Change Request we can't actually make with regard to this version of the Primary Base Schema, I do want give an example of what we CAN realistically do at this time.

In any event, an example of a small change that would be feasible for this version is the change of the name of HumlNameElements to HumanNameElements, which I have added to the list below, (and I am still hoping to hear some advice on this).

Now, for what we CAN'T realistically do before calling for a vote Monday.

Just because I would not make any large changes before we vote on the current Primary Base Schema does not mean that I do not think that it is well worth giving such changes some earnest and honest consideration. The two concepts are only mutually exclusive for the immediate purpose of voting this version up or down.

I say that for a good reason. There is an underlying structure to the Human Markup Language that is only now emerging from the process of assembling this first basic collection of elements, attributes and the related simpleTypes and complexTypes and attributes, datatype and attributeGroups.

So far we have built our Primary Base Schema based on our item-by-item discussion of the strawman HumanML Schema that Len Bullard built for us more than a year ago, in what we now refer to as Phase 0. It is what I would call a flat, relatively unstructured schema and that is perfectly acceptable.
 
The philosophy behind that formulation was to try to use the smallest set of elements upon which the language could be built based on information we have good evidence in current usage is important or significant about human identity, characteristics and communications. Len's viewpoint from within the public safety sector of society and in relation to information compiled in current and legacy databases gave him a very well-grounded perspective for this task.

When we release the Primary Base Schema for the 30-day public-comment period it will mark the end of Phase 1 which consisted of formally defining our Requirements and assembling the first component of the set of XML Schema Vocabularies for HumanML. What lies ahead is assembling the second component of the set of XML Schema Vocabularies, the first of our RDF Schema Reference Libraries, formalizing our Ontological Frameworks and Taxonomical Enumerations, and building our Cognition Model and Semiotic Processing Model.

What follows is the current set of components of the Primary Base Schema followed by a higher level breakdown of structural categories that appears to be emerging from this collection and a brief discussion of what I think is missing in this set of fundamental components and my opinion of how we should accommodate those considerations.


Elements

Huml  - Root Element-should all be child elements to unify the entire Human Markup Language.

Complex types
Address
Artifact
Belief
BodyLocation
Channel
Chronemic
Community
Culture
Emotion
GeoLocator
Haptic
Human
HumanGroup
HumlNameElements (change to HumanNameElement requested)
Intent
Kinesic
Measurement-Unit
Personality
Proxemic
Semiosis
Semiote
Sign
Signal
Symbol
Thought

Simple types    
Locator
range

Attr. groups
age
gender
humlCommAtts
humlIdentifierAtts
humlTemporalAtts
physicalDescriptors

Sections: Current Order:



Human Physical Characteristics
BodyPart
BodyLocation

Communication Modes and Constraints
Kinesic
Haptic
Chronemic
Artifact-?

Internal Human States
Belief
Emotion
Intent
Thought

Channel Types
Channel

Semiosis
Semiosis
Semiote
Sign
Sugnal
Symbol

Individual Human and Identity
Human
HumlNameElements
Address
Personality

Human Group
HumanGroup
Community
Culture

Extensions for World Descriptors and Contexts
GeoLocator
----------------------------------------------------------------------------------------------------------------------

There appears to be a structure emerging that looks like this:

Overall Environment Context:
Physical Dimensions
Measurement-Unit
Locator
Extensions for World Descriptors and Contexts
GeoLocator

Communications-Related
Communication Modes and Constraints
Kinesic
Haptic
Chronemic
Artifact-?
Channel Types
Channel
Semiosis
Semiosis
Semiote
Sign
Signal
Symbol

Human Characteristics-Related
Individual Human and Identity
Human
humlNameElements
Address
Personality
Internal Human States
Belief
Emotion
Intent
Thought
Human Group
HumanGroup
Community
Culture

----------------------------------------------------------------------------------------------------------------------
The components I think are missing are: 1-a working model of individual and social/cultural cognition-perception; and, 2-a category or set of components to accommodate social, political, linguistic, economic, scientific, academic, philosophical and historical theories and studies--in other words the corpus of human knowledge. I don't think we should attempt that, but we should somehow acknowledge that it exists and that we have a relationship to that body of knowledge.

My opinion is that the Primary Base Schema is the not correct place to add those very large sets of components. I do think, however, that they fit within these broad emergent categories. I also think we should add some allowance for them to the Requirements Document which needs to be updated with a mechanism of adding components to this and all HumanML schemata, and a section on architecture based on what we see emerging as an underlying structure.

In addition, I think that eventually we will want to give some consideration as well to starting work on requirements for specific APIs in the subcommittee specifications.

I also have a strong concern about the Communications-Related group because it is not based on what seems like common sense organizational principles to me. That would be to have channels divided into input-sensory channels and output-expression channels. I think that Chronemic, Haptic, Kinesic and Artifact belong in the output-expression category, as sight, hearing, touch, taste, smell and kinesthesia belong in the input-sensory channels.

It may seem strange but I am actually leaning toward voting against this version for that reason. As I said in my own post about Change Requests, I would not make so large a change in this version, and I am prepared to live with this flat schema as is. The fact that I'm a structuralist doesn't mean that there are no ambiguities in my idea of what the structure should be, nor good value in what we have built here.

Lastly, I wonder if a more structured approach might actually be more useful for the eventual APIs we need to consider providing. This would require some Global complexType Elements for the major divisions we see emerging here.

I would suggest EnvironmentContext, HumanCharacteristic, and Communication as the three Main Global complexType Elements which would be an explicit sequence from the root Huml Element.

Then each of the existing sets could be sequences from those,

I would also suggest that there be only three main divisions in Communication: SensoryChannel, ExpressionChannel and Semiosis.

HumanCharacteristic would be divided into HumanIdentity, HumanInternalState and HumanGroup, which would require only two new elements to be the parents of the sequences for Identity and InternalState since we already have HumanGroup.



 

 



-- 
Rex Brooks
Starbourne Communications Design
1361-A Addison, Berkeley, CA 94702 *510-849-2309
http://www.starbourne.com * rexb@starbourne.com


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC