[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [humanmarkup-comment] Actions In Context [was: Re: HumanMarkup:Paved With Good Intentions]
> 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC