[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