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: [humanmarkup-comment] Base Schema-bodyLocation


Okay. I will get back to thinking about this again tomorrow morning. 
My brain is being hijacked by the usual suspects of daily routine and 
tasks of various sorts. I hope a few things turn out well to enable 
some of us to spend more of our time on this work. I have this 
perennial feeling that I'm missing something, usually several 
somethings.

Ciao,
Rex

At 9:08 AM -0500 5/20/02, Bullard, Claude L (Len) wrote:
>Separating bodyLocators from geoLocators should present
>no problem.  The generalization of location has to account
>for the coordinate system that is best for the system over
>which it has scope.  I don't see the need for using
>bodyLocators, really, enumerated names for common
>body parts in contexts that use geoLocators.  GeoLocators
>and addresses have to be associated to enable verification
>via other systems that use map-based interfaces.
>
>A typical application of bodyLocations is to describe a
>location for a scar, mark, or tattoo, jewelry, etc.
>
>len
>
>-----Original Message-----
>From: Rex Brooks [mailto:rexb@starbourne.com]
>
>Well, I've gone from a pace quicker than expected to one much slower
>than expected, with expected being three elements a week. This one
>posed, and poses, a lot of considerations, and will undoubtedly spawn
>a host of elements in the Base Schema as well as being the foundation
>for much of the Human Physical Characteristics Description Markup
>Language. So that was a warning, Rob, we will be needing to keep a
>close watch on this thread to gather up new elements.
>
>Note: For those of you who are not already familiar with some of the
>background material, I will include the urls for the material, but I
>really can't expound it thoroughly or this message would be far too
>long to read. You'll just have to do the study yourselves.
>
>bodyLocation
>
>This is a Complex Type which locally defines a location on a body
>part, and is described as being used in haptics, artifacts, etc.
>
>Before I launch into the more detailed aspects of this element, let
>me say that this element represents the problem of derivation, and
>hence the follow-on problem of inheritance and somewhat less, the
>interconnected  problems of polymorphism and multi-schemata usages.
>It also points up yet another difficulty of the alphabetic approach.
>
>For derivation and alphabetization, it derives from a later element,
>locator which is in turn derived by restriction from xsd:string. The
>issue it brings up is the organizing principle that underlays it.
>Because it is defined by being a location on a body part, it appears
>that it is related to the body part in the self-referential way that
>locator specifies by its enumeration values of "upper, lower, back,
>front, etc."
>
>I still think alphabetical order just makes it easier to keep track,
>but we do need to bear derivation in mind, because, even though we
>are not now creating a class system per se, derivation lays the
>foundation for it, and to keep later applications from having
>problems, we need the derivations to be clear.
>
>In this case, the longer I thought about the necessity to harmonize
>with the terminology of both H-Anim in VRML97/X3D and
>medical/biometrics vocabularies, the more I became convinced that
>this element needs to be better organized.
>
>For harmonization, it needs to be tightly associated with the Site
>Node of the H-Anim specification:
>
>http://www.h-anim.org/Specifications/H-Anim2001/Site.html
>
>That said, let me just say that I am following these issues in the
>order they occurred to me rather than in the outlined, numbered,
>term-paper form I usually employ for such things. In this case it
>follows the train of associations raised by my personal
>interests--real time, multi-user, 3D, human-based computing. So,
>H-Anim comes first. I also want my personal biases clear, at least
>when I am aware of them.
>
>So, I believe that this element, while it has uses beyond this, is
>likeliest to be used as sites for artifacts to be worn on the human
>body, or to specify parts of the human body. And because human in
>this schema, is largely a container for sensory input channels, which
>is what it really refers to in digital information system terms, I
>think we need to break this down into a more clear derivation of
>elements, thus:
>
>human (which we will get to in alphabetical order) which needs to be
>slightly expanded from the narrowest defintion to include the idea of
>having characteristics , largely sensory channels, still (and hence
>characteristics sets which lays the foundation for the HPCDML, as
>well as for, medical, biometric and  H-Anim harmonization).
>
>humanBody This seems fairly self-explanatory, but I want to mention
>that it would refer to either the representation of a human body in a
>digital information system for interactive or entertainment purposes,
>and medical/biometric specific information relating to a named human
>individual biological entity.
>
>humanBodyPart This is a tentative name only, could be
>humanBodySegment, humanBodyOrgan, etc--this is definitely needed in
>the Base Schema to lay a clear foundation for HPCDML, VR-AI, etc.
>This needs work, and I'm stretched too thin to take this on, but I
>definitely would if I had greater capacity
>
>humanBodyPartSite This is also a tentative name only. It could be
>humanBodyPartLocation, or it might be extracted as simply
>humanBodySite.
>
>Following are the resources with which we need to harmonize, and it
>specifically does not include medical/biometric because I am
>soliciting help from that community--HINT!
>
>Anthropometric Landmark VRML Glossary:
>
>http:ovrt.nist.gov/projects/vrml/h-anim/landmarkInfo.html
>
>CAESAR: Civilian American and European Surface Anthropometry Resource:
>
>http://www.hec.afrl.af.mil/cardlab/caesar
>
>
>I think a clear derivation is necessary for how we arrive at an
>element which will be used in various application areas. I do not
>have a difficulty using Locator in tandem with human to humanBody to
>humanBodyPart or Segement or Organ since we also use it clearly in
>geoLocator, a little later on, which also will be heavily
>cross-referenced in divergent application areas.
>
>I think that's it for me on this one. I haven't gone into the
>implications for cultural usages or taboos related to bodies, body
>sites, and wearing artifacts because I didn't see a particular need
>to do more than assure a clear foundation for how we use the
>reference system to the human body.
>
>Ciao,
>Rex
>--
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>


-- 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC