[humanmarkup] Base Schema-bodyLocation

[Rex Brooks <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
--