[humanmarkup] PBS-Doc-bodyLocation

[Rex Brooks <rexb@starbourne.com>]

Title: PBS-Doc-bodyLocation

Please note: Our initial discussions around address and artifact contained the largest collection of discussion posts that ranged into overall considerations of the entire schema and some of those discussions were duplicated in those compendia, but until we got close to the end of the process, similar discussions occurred only around the semiotics processor concept which is likely to take the place of the grammar concept that was developed in the address-artifact discussions. And, of course, as we neared the end of the first pass, we collected up our new elements and went through them before proceeding on to this process.

So many of the remaining elements, attributeGroups and datatypes produced much less discussion.

---

Subject: [humanmarkup-comment] Base Schema-bodyLocation

             From: Rex Brooks <rexb@starbourne.com>
             To: humanmarkup-comment@lists.oasis-open.org, humanmarkup@lists.oasis-open.org
             Date: Mon, 20 May 2002 06:38:01 -0700


      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
      --


Subject: RE: [humanmarkup-comment] Base Schema-bodyLocation

             From: "Bullard, Claude L (Len)" <clbullar@ingr.com>
             To: 'Rex Brooks' <rexb@starbourne.com>,humanmarkup-comment@lists.oasis-open.org,
             humanmarkup@lists.oasis-open.org
             Date: Mon, 20 May 2002 09:08:30 -0500


      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

-- 

Rex Brooks
Starbourne Communications Design
1361-A Addison, Berkeley, CA 94702 *510-849-2309
http://www.starbourne.com * rexb@starbourne.com