[humanmarkup] RE: [humanmarkup-comment] Base Schema-address

[Rex Brooks <rexb@starbourne.com>]

Thanks, Paul,

I agree, creating a set of classes is just another step down the 
road. I didn't suggest it as an end, I was only pointing out that for 
general programming purposes, such as fundamental interoperability 
and agreement between various vocabularies, and object processing 
across the web/net, building such a set of classes, very carefully, 
is, IMO, inevitable.

As far as the AI issue is concerned, we have a subcommittee that is 
exploring that, and while I have my own thoughts on the subject I am 
satisfied to let that develop within that subcommittee.

I don't think this thread is appropriate to speak to that issue. In 
this context, what we are doing now is going through our Base Primary 
Human Markup Language XML Schema item by item to examine it 
thoroughly and methodically. The AI-VR Subcommittee is concerned with 
this process as are all currently envisioned extensions, or secondary 
schemata, as we have termed them. The Base Schema needs to contain 
the elements upon which these extensions can be built.

So the work of deriving and harmonizing classes for OO programming 
purposes is not likely to begin in earnest until after the Base 
Primary and subsequent Secondary Schemata have been written, 
discussed, and submitted to OASIS as Recommendations. And then it may 
well be that the task itself will be more in the nature of 
harmonizing between and amongst the variety of applications that 
hopefully will have been developed as implementations by then. I can 
vouch for at least two such applications myself: a middleware 
movement and gesture language to drive the H-Anim Specification of 
the upcoming X3D specification which will provide for standard bodily 
and facial gestures for 3D representations of humans; and a 
meeting/presentation audience monitoring or collaborating tool that 
generates and presents reports that use HumanMarkup in addition to 
other more standard toolsets.

We have subcommittees for Physical Characteristics Descriptions and 
Diplomatic Communications as well as AI-VR, so it is likely to be 
quite a while before we can truly address the topics you are 
suggesting.

By then, perhaps, such technologies as you are working toward may be 
able to adapt our work, or, perhaps, a Stratified, Adaptive Human 
Markup Language could be developed. However, if it is possible to 
extrapolate what a Stratified, Adaptive Human Markup Language might 
require, it would be wise of us to make an accommodation to allow it 
to be more easily developed. However, for now, we need to be as 
concrete and immediately useful as we can in order to garner 
acceptance and support. Our success depends on it.

Being mindful of concerns which may become desireable or necessary is 
a good idea, too.

Ciao,
Rex


At 4:03 PM -0400 5/13/02, paul wrote:
>Ultimately agreeing to a set of classes is not the eventual state of
>intellectual evolution.  It is in fact an illusion.  Object-Classes are
>useful as a way of boot strapping into the organization of process flow and
>data realization.  However, once we accept this bootstrap as the final goal,
>we lock ourselves into a strict reductionism and is often seen as the AI
>Dream (that a machine can think).  This is not appropriate for human markup.
>
>However, there is some good work by Tonfoni
>
>http://www.bcngroup.org/area3/gtonfoni/tonfoni.htm
>
>that I wonder if the members of the human markup committee are aware of.
>
>
>It may be ok in technology communities to banter around this AI Dream as if
>the dream
>
>1) is a reality
>and
>2) is a desirable end state to the evolution of intelligence
>
>However, the natural science community is becoming more and more unhappy
>with this Dream.
>
>Other standards communities (Topic Maps for example) have already
>experienced the go around on this issue, and may wish to think that issues
>like scope are being addressed in a profound and completely fulfilling
>fashion.  But scope, like context is not so easy to reduce to an exact and
>precise ontology.
>
>New intellectual machinery is needed, and part of this has to do with the
>non-reducibility of intelligence to algorithms and exact specification.
>
>I will discuss some of the issues regarding this, if there is interest.  My
>comment is not made as a personal insult or an attack on anyone... however
>there is a principled argument that scope, viewpoint and context require an
>extension of the Complex Adaptive Systems thinking to what is called
>Stratified Complexity.
>
>http://www.bcngroup.org/area3/pprueitt/book.htm
>
>
>Paul Prueitt
>
>
>
>
>-----Original Message-----
>From: Rex Brooks [mailto:rexb@starbourne.com]
>Sent: Monday, May 13, 2002 11:27 AM
>To: humanmarkup-comment@lists.oasis-open.org;
>humanmarkup@lists.oasis-open.org
>Subject: [humanmarkup-comment] Base Schema-address
>
>
>Hi Everyone,
>
>Please keep these threads within the Subject Line that initiates
>them, for easier reference. The elements are arranged in alphabetical
>order and this seems like the most sensible way to organize it. I
>will follow that organization in discussing them.
>
>It has the value of being accepted as not implying any kind of
>hierarchical or other classification system. As someone joined at the
>hip to OO, it also makes it easier for me to remember that we are not
>creating classes, yet. I add the yet because at some point, once we
>start building applications, we will, of necessity be brought to the
>task of agreeing upon a set of classes, but that is so far downstream
>from this point in our development that it need not concern us
>greatly.
>
>I will go through them, as nearly as possible in the order they
>appear: element definitions first, global attributes and then
>datatypes.
>
>Even as we go through this exercise, it is certain that we will
>develop new elements as they occur to us and as the subcommittees
>begin to identify the elements they will be needing, but I think it
>will be easier to spin those discussions off into separate threads,
>for which I suggest we use a variation of this Subject line, thus:
>New Base Schema Element-element name.
>
>That said, our first element:
>
>address
>
>This is a Complex Type and it is specified as a named address system
>such as street, city, state, etc. It is noted that when this element
>is used it will be code-based, i.e. an instance of an accepted,
>existing, named addressing system in international use.
>
>It is further specified that is a member of the xsd:attributeGroup
>referenced by "humlIdentifierAtts"
>
>Because it is a variable value that will change over time, it is not
>a Global Attribute.
>
>All of that is fairly straightforward and I doubt anyone can have
>much concern about it, however, what occurs to me is the question of
>whether we might want to distinguish between residential addresses,
>postal addresses and email addresses, although email is a bit of an
>orange in this box of apples, so to speak. However, for the purpose
>of sending communications or freight, and tracking such things for
>double checking accuracy, for instance in the case of multiple
>individuals sharing the same name, it might be good to have these
>distinctions under different elements, or additional attributes
>within this element.
>
>Okay, we have a number of ways in which this element can be used. And
>these ways also come into play in how we structure this element. I
>can think of several scenarios where the distinctions I mentioned
>above will be of vital importance:
>
>Scenario 1: Emergency Services Delivery in a natural disaster, where
>two Joe Smiths live in the same town where a tornado has struck and
>both have special medical needs that need to be taken into account in
>case they require emergency medical care on the scene of the
>disaster. Both have verifiable internet identities, email addresses,
>etc. Can address information help?
>
>Secnario 2: Joe Smith, tenant at 12345 Mill Rd, Oceanview, New Jersey
>receives mail for a former tenant, and it appears to be an important
>and time-critical piece of information. All he has is a name. Is
>there a chance that he can get the correct address in a secure way
>that does not tell the wrong person what kind of information he is
>seeking to redirect to its proper recipient?
>
>I will leave it at two scenarios. I have used examples here that I
>have had actual experience with in my own life except that I simply
>added a second person with the same name for a scenario 1 based on an
>incident where my neighbor had an asthma emergency, and the neighbors
>did not know he had asthma, only that he was apparently unable to
>breathe. It turns out that I later developed a kind of asthma myself,
>fortunately not triggered by stress like his, but emergencies can
>easily trigger this kind of subsequent problem. I have also received
>mail for at least two other Rex Brooks and you might call that a bit
>unusual, so I also know that these kinds of situations can occur. For
>more common names, I am sure this kind of thing is not really unusual
>at all.
>
>So, this is what I intend to do as I go through the elements in the
>HumanML Schema Len diligently worked up for us in Phase 0.
>
>I will try to do at least 3 a week, rather than one a day, though
>even that may be optimistic.
>
>Ciao,
>Rex
>--
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>
>
>
>
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>


--