RE: A Library of Taxonomies [was Brass Tacks #2]

["Bullard, Claude L (Len)" <clbullar@ingr.com>]

I concur.  Right now, we only have a few use cases.  
I am not looking for application code, but the 
properties that an application needs.   

The EMOTE example is revealing in that it uses a specific 
set of parameters to feed the engine and these 
are based on a high level metaphorical description 
of movement.  This *metaphorical* aspect is what 
enables the observer to take observations and put 
them into the system at a level which the human 
observer can work with well.  When looking at the 
psychological theories, one sees a similar metaphorical 
aspect:  the observer is seldom actually measuring, 
but filling in forms based on their estimates of 
how the observation matches the metaphorical properties. 
These are provided to the engine which then renders 
the model based on the inputs.

One might inquire what test is used to determine when a 
model (the observation metaphor) is getting reasonable 
results.  Albeck could tell us how EMOTE is tested 
for 'reasonableness' but I suspect it is feedback 
by observation.  Still, **the requirement to create a 
metaphor whose qualities make it easier to observe 
and/or record information that produces a reasonable 
rendering seems to be the best and most useful test 
for a HumanML candidate with the proviso that the 
candidate may work itself by transformation to a 
language such as EMOTE where possible.** 

Some use cases can result in languages that are reusable 
because the metaphor of the language can be applied and 
well understood in what otherwise seem to be different 
domains.  Scene/actor/speech metaphors are used for 
creating plays/movies etc and also applied to user 
interface design use cases (See Richard Due, et al). 
It is simply a widely applied metaphor for communicating 
systems.  What would HumanML contribute to differentiate 
these uses?  Again, I return to an earlier post from 
phase 0 on what does it mean to be human, then 
what does it mean to be a human communicating in a 
context.   Perhaps we need a synopsis of each 
of the domains we looked at thus far to precisely 
define what they contribute.

It has never occurred to me that we would create a 
single unifying schema.  It seems more likely that 
we would create and refine by iteration multiple 
descriptions and types and try to apply these as 
you say to the application languages.    A set of 
URNs are one way to create families or simply, 
mark out the domains.  It is a tool, though, not a 
solution per se.  


Len 
http://www.mp3.com/LenBullard

Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h


-----Original Message-----
From: Kurt Cagle [mailto:cagle@olywa.net]

Most of the phase one are was really oriented around deciding where the
boundary between Application and Content should lie, something that I think
is still not fully resolved. It occurs to me that one exercise that may be
worthwhile for all of us individually would be to take the schema as it sits
right now and compare it with where our particular needs are, then compare
notes with one another (perhaps in Rex's Libraries). This may very well
expose holes in the schema, but I think it may also help to more clearly
delineate what we see as pressing needs for the schema vs. what would be
nice-to-haves that may in fact be more adequately handled by a modular
schema extension of some sort. Certainly the sense that I get right now is
that there are a lot of people who look upon HumanML as sufficiently
amorphous that it could solve their tasks, whereas I agree with Rex that we
need to start thinking of this from a more functional viewpoint.

The real danger with HumanML is that it could very quickly explode into a
structural domain of all human endeavors, which I think would be ultimately
futile.  On the other hand, I think if we do move back to the modular
approach that many of you agreed upon early on in this discussion at this
stage, then it will help us more adequately figure out ways of creating just
such a tree without ruining our day jobs in the process <grin/>.

One idea that I've had percolating for a little while is to actually move
away from the idea of creating a formal single schema, but rather towards
building a framework for taxonomy and a "Dewey Decimal System" for
integrating various taxonomies - a taxonomy of taxonomies if you will. Any
given domain of interest will have multiple schemas associated with that
domain for the purpose of describing different entities in that domain ...
the entities may be fairly similar, but not necessarily identical, and such
entities tend to arise spontaneously in response to need. We currently have
a kind of ad hoc indexing mechanism in the form of URNs, but those URNs are
organized largely around organizational needs rather than topical ones.

This raises some other major issues, admittedly, but it occurs to me that
such an effort would not only help make a HumanML system viable, but it is
also something that would have application to all groups within OASIS. You
could effectively reference a Business Process schema as something like
"urn://business/oasis-org/ebxml/process/2001/08/11/125A" while a schema for
describing ancient greek mythology might be something like
"urn://sociology/religion/ancient/hellenic/legends/2001/07/09/36B". This
would not only make modularization easier, but it also provides a way of
seeing in a comprehensive fashion what already exists.