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

 


Help: OASIS Mailing Lists Help | MarkMail Help

humanmarkup-comment message

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


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


Oh, I don't think we should drop locator. Now that I understand it 
better, I think it is absolutely necessary that we have a low level, 
primary element which is ours entirely but which interoperates to 
extend the standards in place for us. I think that the example of an 
artifact, especially an artifact that is also a cultural symbol with 
important associations for an individual, such as an amulet, a cross, 
a flag, etc needs to capable of explicit treatment such as how it is 
handled, where it is touched and when, etc.

I sometimes ask questions that have apparently obvious answers but 
which I think need explicit explanations, but I also sometimes just 
ask questions because I'm just having a dense moment but which serve 
the same purpose. Not even I know the difference all the time. This 
was a case of one of those dense moments and I really needed to have 
the use made clear for me.

I agree that there are aspects of locator which will be influenced by 
proxemics and vice versa, but they are distinct functions and 
relationships should not be muddied by conflating the two elements. 
As Len points out, and we will have this discussion more fully soon 
since proxemic is coming up shortly. Proxemics carry personal 
information beyond immediate physical relationships to objects and 
persons.

I also want to ask if we should add a third locator to our current 
count of two, to include Sylvia's suggestion of a geo-temporal 
locator to geolocator and locator, or do we think that combining the 
geolocator element and the chronemic element together to describe an 
object's location physically and temporally is sufficient?

Ciao,
Rex

At 9:09 AM -0500 9/16/02, Bullard, Claude L (Len) wrote:
>Yes.  A locator is just a placeholder for a set of names
>of relative locations for objects based on natural language
>descriptions.  Proxemics takes on social distances among
>the semiotes (eg, should also take up the rules for social
>intercourse and how they affect distance).  In a proxemic
>definition, we should be able to discern given a cultural
>orientation and personal history if the distance a speaker
>has to another speaker indicates potential discomfort, dominance,
>intimacy, etc.
>
>Locators aren't that interesting an element type.   They could
>be dumped without much loss.
>
>len
>
>-----Original Message-----
>From: Ranjeeth Kumar Thunga [mailto:rkthunga@interposting.com]
>Sent: Sunday, September 15, 2002 2:05 PM
>To: humanmarkup-comment@lists.oasis-open.org; rexb@starboune.com;
>Bullard, Claude L (Len)
>Subject: RE: [humanmarkup-comment] Base Schema - locator
>
>
>The particular code list below, to me, seems like 'proxemics'.
>
>The distinction, as I currently see it, is that 'locator' would be
>simply an absolute reference for objects, while 'proxemics' would be a
>relative reference, relative of course to other semiotes, or possibly
>physical objects.  Does that sound right?
>
>Ranjeeth Kumar Thunga
>
>
>
>
>-----Original Message-----
>From: Bullard, Claude L (Len) [mailto:clbullar@ingr.com]
>Sent: Friday, September 13, 2002 10:09 AM
>To: 'Rex Brooks'; 'humanmarkup-comment@lists.oasis-open.org'
>Subject: RE: [humanmarkup-comment] Base Schema - locator
>
>
>Without locators, you have not way to provide a spatial
>context for other objects.  It is there as a placeholder
>to note that fact.   When you break down the parts of
>any assembly, you generally denote these in terms of
>say "upper", "lower", "upper right" etc.  This is a
>code list for simple descriptions of locations relative
>to each other.
>
>len
>
>
>From: Rex Brooks [mailto:rexb@starbourne.com]
>
>Hi Everyone
>
>Onward...
>
>locator
>
>The element is Complex Type, derived by restrictin from xsd.string is
>not classified as abstract.
>
>It does not reference other elements. It is not used by other elements
>
>It is described/defined as a simple set of names of locations ON an
>object.
>
>I don't have a lot to say about this one except that I'm not sure why
>we need it. I don't object to it, and I'm not suggesting we delete
>it, I just don't know what the special use is that we have for it
>that raises it to the level of necessity for inclusion in the base
>schema. I understand body location on a human object, but I'm not
>quite sure about locatin on an object per se. I suspect that like a
>few other things that don't seem obvious to me, as soon as someone
>shows me an example of how it would be used, I will do a Homer
>Simpson, apply palm to forehead and utter a plaintive, "Doh!"
>
>Anyway, I'm not gonna have a cow about it.
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>
>
>---
>Incoming mail is certified Virus Free.
>Checked by AVG anti-virus system (http://www.grisoft.com).
>Version: 6.0.384 / Virus Database: 216 - Release Date: 8/21/2002
>
>
>---
>Outgoing mail is certified Virus Free.
>Checked by AVG anti-virus system (http://www.grisoft.com).
>Version: 6.0.384 / Virus Database: 216 - Release Date: 8/21/2002
>
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>


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