Re: [humanmarkup-comment] Actions In Context [was: Re: HumanMarkup:Paved With Good Intentions]

[Kurt Cagle <kurt@kurtcagle.net>]

> XML Schema does have inherent set of constructs for doing such thing:
> substituition groups and xsi:type denotations especially, *but* (and this
> is a big but) they are syntactically oriented only. This is a weird aspect
> of XML Schema, in that it lets one create metasyntactic structures such as
> groups of elements, but that it does not underline the semantic
consequence
> of such things. For example, it may well be that I am grouping a set of
> elements under a substitution group to save space in the schema. On the
> other hand, it may be that I'm grouping these elements together because
> they share common semantics. I think that it's odd for a syntactic
language
> to have constructs that are so synonymous with denoting semantics of a set
> of elements, and yet has minimal documentation as to why this is so, or
how
> to use it effectively.
Agreed. That was in fact one of the reasons why I didn't just suggest
substitution groups, though I am aware of them. One of the characteristics
that I see intrinsic in all of this discussion is that HumanML *is* a
framework, and not just a schema. Like any framework, the specific
implementations of the framework are environment specific, though in this
case the environments are domains of usage rather than operating system
constraints. Indeed, a big reason for the modularity that I was pushing back
in August has more to do with the fact that we are dealing with different
fundamental semantics depending upon the application involved; the current
recommendations attack the same problem from a different standpoint.

> That's a murky area of XSD, and I don't like murky areas of technologies.
> In any case, I'm expending a little background material there at the cost
> of going off topic. To get back to the subject in hand, your xlink:def
> attribute is a good idea, but I think you actually mean:-
The substitution group concept in XSD has been one of the biggest sticking
points I have about the spec in the first place. It's complex, awkward, and
doesn't really seem to solve the problem it is intended to solve (sort of
like HumanML in some ways).

>      <nonEmotiveElement level="35"
>         xlink:href="http://www.hml.org/schemas/xyz/percent"
>         xlink:role="http://huml.org/#def" />

> or you could annotate the instance using a language which shall at this
> point remain nameless :-)
The usage of role here actually makes a great deal of sense. It decouples
the reference from its implementation, and goes with existing notation (I
wasn't happy with xlink:def myself, but I don't think that xlink:href by
itself got the point across as effectively).
>
> > [...] (happy is a verb).
>
> As in "you're to happy today"? :-) "Happify" would be the verb form of the
> adjective "happy"!

Okay, so happy is an adjective <grin/> but it still is an aggregate
indicator of other, more demonstrable characteristics. Actually, I can
almost see a syntax emerging here, based upon constraints:

def happy := [smile1>.35, smile2>.45, posture >.65,etc.]

Emotiveness IS a part of what HumanML is trying to do, but the problem is
that you cannot directly provide a measure of emotiveness that isn't by its
very nature fuzzy an inexact; all you can do is define a set of vectors
(properties) that when taken together, are indicative of the state; note
that this works in the opposite manner as well. If you wanted to associate
with an avatar a "happy" state, you'd have some corresponding functional
mappings that go in the other direction:

setHappy(level):=[smile1 = level*0.65 + 0.35; smile2=level*0.55 + 0.45;
posture*0.35 + 0.65]

thus setHappy(0.5) will produce happy = [smile1: 0.67; smile2:0.73;
posture:0.82]

I think this also illustrates a point that Sean was trying to make before -
the real goal of HumanML is to effectively provide a minimum set of vectors
that can most uniquely characterize human interactions. happy() can be
decomposed, hence it's not minimal.

-- Kurt