OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

humanmarkup message

[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