RE: HumanMarkup Reservations

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

The existing schema is not modularized yet because

we weren't to that point.  The need for it is obvious

enough yes and all of the email reflects that from

a very early stage.  We have only the one namespace

prefix because we only needed one so far.  Modularization

changes that, but until someone spends time showing

how and where, it is easier to manage in one.  

 

In the phase 0 there were about

70 members of which about six or seven were actively

contributing.  We started just as XML Schema was

emerging from finals so we've been learning that

tech.  As the schema author, I took it to a

very preliminary state based on the research

and stopped knowing that OASIS was the next

stage and most of us were somewhat exhausted.

 

Avatars are one application.  HumanML has to

be a toolkit for others to create more specific

application languages similar to the way

XML Schema is an application language.  We

have an early emphasis on that because of

the early contributors, several of us are very

interested in interactive fiction and yes, that

is much like role play.  On the other hand, a

public safety system has a limited use for

simulation and a large need to exchange

profiles for analytical systems.

 

Suggest:

 

o  Interoperability among implementations that

use HumanML is out of scope at this time.

 

o  Issues such as how to coordinate the

Schema and RDF work are in scope. 

 

o  Issues such as RDF is so much better

than Schemas are out of scope unless

we need a functionality only one can

provide.

 

HumanML is likely to be very mundane work

for the CS majors.  The kinds of things that

obsess XML-Dev are best debated there.  We need 

humanities majors for whom this subject matter 

is their field of expertise.   We need implementors

who need human-centric data for their applications.

 

For HumanML, Schemas, RDF, etc. are tools.  Issues

such as Java over C++, MS over Sun, the W3C over

ISO, and so on are out of scope.   Issues such as

"based on documented research and tests, a

single intensity attribute for gestures is inadequate"

is in scope.

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

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

-----Original Message-----
From: cagle@olywa.net [mailto:cagle@olywa.net]
Sent: Thursday, August 23, 2001 11:29 AM
To: humanmarkup-comment@lists.oasis-open.org
Subject: Re: HumanMarkup Reservations

Another throught that occurred to me on this. I am increasingly becoming convinced that modularization is going to have to be an integral part of the final rec. There are simply too many domains of endeavor to want to try to dump them all into a single namespace, even if you keep the focus of HumanML limited. I'll admit to being delinquent on reading what's up at HumanML.org, but in studying even the first draft schema the need for creating modular components was pretty obvious. I see a single overall framework ns, call it hm: for now, that serves primarily as a binder, and may in fact also be responsible for identity, though I have some reservations about that, because I think that with avatars you have the very real possibility of having multiple identities associated with the same individual. I'll have to study the docs more on that one.

 

There is also the question of relationship between identity and access -- to me this is an intersection point between HML and the ACLs group, since realistically there will need to be some way of determining whether a given identity can be associated with specific access privileges.

 

Describing emotional states strikes me as being a modular function, so perhaps an (hme:) namespace would be useful here. Avatar description, likewise, may need to be its own namespace (hma:) that would cover presence issues -- what a given avatar "looks" like, what functionality that avatar has, and so forth. This might also link to an avatar's "possessions" -- an RDF section that would essentially provide a map not only to specific instances of an object (presumably through some type of key) but also to schemas describing these possessions.

 

Before I'm accused here of thinking of this as a role-playing game (though some of that is there), let me give you an example where I see possessions as being relevant.  Suppose that you have an online classroom where each student has, as possessions, sets of homework. You don't want to include that homework in the HML description explicitly, but you do need to make sure that a mechanism exists (RDF, presumably) so that a teacher can retrieve that homework for review, can retrieve the grades that the student received for report cards, and so forth. That this information may be contained in a database somewhere is irrelevant -- from the standpoint of the markup, that database entry is still a URL target in a relational map.

 

Okay, I'm drifting a bit, but I do think that the issue of domains and modularization is very highly linked, and is something we need to consider before we get to even a first WD stage.

 

-- Kurt Cagle