[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [humanmarkup] Re: PBS-Doc-human and humlNameElements(commentary)
Hi Everyone, I am forwarding Sylvia's post with my reply since I am done with my first raw pass, and since I have already answered Kurt's concerns, it only makes sense to include this post in that process. I changed the subject line slightly in my reply to Kurt, and I am making the same change here, so if you have a reply to that post please reply specifically to that post and likewise for this one. In case it was lost on anyone, the barrage of documentation posts i have been making are pretty clear evidence of how that works, and I am using the same process here in our (commentary) period. >re HUMAN, >Is this the kind of thing we're working toward? > >If someone wants to specify homo sapiens sapiens, we could let that be a >secondary. >Etc. (HUMAN: homo sapiens sapiens: H34) which could presumably combine with >whatever our version is of (IDENTITY: H34) where I'm assuming H34 can be >anonymous, group, pronoun, or name, or other identifier(s) .... > >If someone means human-like or human-adjunct, science fiction has worked out >"humanoid" (for a complete, embodied workalike) and probably some other >usable terms, although human-like or human-adjunct and such could perhaps >serve as fruitful secondaries too. >(HUMAN: humanoid: VRML_Matilda_URL) ? Just so you know H-Anim which I refer to often in regard to the H-Anim 2001 Specification and the working group of the same name at the Web 3D Consortium stands for Humanoid Animation, so humanoid is already associated with an ISO standard. >We might end up with cases having embedded human voice generators >and so forth, >(HUMAN: humanoid: Voice-generator: parameters( voice-of-personPx, >Px=WHO, etc.) >along with (HUMAN: WHO). > >And if a person was using one of these generators, there'd be combinations: >(HUMAN: homo sapiens sapiens) >(HUMAN: humanoid: VRML_Matilda_URL) >(HUMAN: humanoid: Voice-generator: parameters( voice-of-personPx, >Px=WHO, etc.) Correct. The spec doesn't need to change (below), it supports a wide range of humanCharacteristicSets. >So our spec would be HUMAN* (reappearing feature)? >Note that these are basically predications. (Caution: there are lots of >value judgements in this range. Would a ghost be under this category?) Our spec in the Secondary will enumerate any further sufficiently large and well-supported types of human, such as humanAgent bot program or a particular kind of humanCharacteristicSet modifier module, or for a specific instance of UserAgent such as a personalized web browser that acts in a "human" capacity for an authenticated identity. Individual named instances of the element will become human objects in the OO sense if someone, like me, uses it that way. I expect to cheer happily from the sidelines, when I get the time, as we move through a much longer, but no less rigorous process for the Secondary. But, yes, all that you say. And individual identities can and will change over time and be correctly updated as we go. >SC >I take it you didn't get a summary for Anthro from James Landrum though he >mentions setting out to do one? > >-------------------- >re HUMANgroup, >A setup as above would allow simply putting a designation of plurality on, >(HUMAN:...) +plural: [optional number or other size specifier as in "crowd") >Presumably we'd have some such thing for objects anyway, in the nature of: >(OBJECT:..) +plural:(size) >Linguistically the null case might not be 1, but rather "number not >indicated". >(By "null" I mean least marked in terms of what linguists call markedness.) > >The bridge case is >{ (HUMAN:...)i, (HUMAN:...)j, ... , (OBJECT:...)a, ...} +plural >which would include all-human, CHI, CCI and the like. > >Then we could discriminate a >SEMIOTIC COMMUNITY >as any group that communicates [?in fact ?potentially] >per the initial diagram (roughly Si /Context i --trans signal / Context k >--> Sj /Context /j with interpretation/generation ) . > >------------------ >maybe that solves that riddle! Oh yeah! It doesn't make any easier to do, just makes it possible. > >SC > > ><snip duplicated material we don't need to continue duplicating. >This is now its own thread./> -- Rex Brooks Starbourne Communications Design 1361-A Addison, Berkeley, CA 94702 *510-849-2309 http://www.starbourne.com * rexb@starbourne.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC