Re: HumanMarkup Reservations

[cagle@olywa.net (Kurt Cagle)]

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