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: RE: [humanmarkup] RE: PBS-Doc-locator(commentary)

Title: RE: [humanmarkup] RE: PBS-Doc-locator(commentary)
Thanks again, John,

For calling our attention to this. Since we are attempting to be as interoperable as possible, we will certainly do our best to get in conformance.


At 7:30 PM -0700 10/24/02, Aerts, John F. wrote:
You may want to review the Los Angeles County Incident Report .xsd for an example. Yes, it is in lower camel case. We will be changing it in November to follow the Federal Guidlines.
-----Original Message-----
From: Rex Brooks [mailto:rexb@starbourne.com]
Sent: Wednesday, October 23, 2002 7:05 PM
To: Bullard, Claude L (Len); 'Rex Brooks'; humanmarkup@lists.oasis-open.org; cognite@zianet.com; kurt@kurtcagle.net; mbatsis@netsmart.gr
Subject: [humanmarkup] RE: PBS-Doc-locator(commentary)

As you can see, I am working my way back up my mail queue from the later to the earlier, adding the (commentary so you all can respond to particular threads and still maintain the useability of the OASIS mailing list archives.

Yep, I didn't leave the Scars, Marks and Tattoos out on purpose, though. I gave it just enough thought to mentally add it to the bucket that contains stuff for the Secondary.

And my point was that if we need a geo-temporal locator we have the tools with which to build it without building a new element or attribute, although if we need it, it can be done, and I am fine with it. Whether a rough observable is sufficient is, I think, up to the appbulders. At least I hope so.


At 3:13 PM -0500 10/23/02, Bullard, Claude L (Len) wrote:
The reason that guy was in there, again, was for simple code lists that locate something
relative to a part.  For example, in Scars Marks and Tattoos (a common and standard
item for police databases), one has to enter that the, say scar, is on the upper right
forearm, or that one exits the "Back of the house" and so forth.   These lists are
convenient but not at all related to geolocators where one has a fixed object
in space (say a railroad track) and it is "five blocks north of the intersection
of E. Street and W. Ave".  And these are time-independent.   Typically, a
geotemporal locator would need to be a complex type that includes the
geolocator and a datetime.   These are more precise datatypes whereas
a simple locator is a rough observable in which precision is not necessary.
-----Original Message-----
From: Rex Brooks [mailto:rexb@starbourne.com]
Sent: Wednesday, October 23, 2002 3:05 PM
To: humanmarkup@lists.oasis-open.org; cognite@zianet.com; Bullard, Claude L (Len); kurt@kurtcagle.net; mbatsis@netsmart.gr
Subject: PBS-Doc-locator

We had rather a lot to say about locator, compared to some others one might think more critical, but hey, that's what discussion is for, right?

In looking at how we resolved this and the issue of a geo-temporal  complexType or attrbute, and it seems to me that this should be decided in the pubic comment period. I think that having a geolocator and humlTemporalAtts can handle the job, so I left well enough alone for now, but I could be fairly easily persuaded that we need a different complexType or attribute.

Subject: [humanmarkup-comment] Base Schema - locator

             From: Rex Brooks <rexb@starbourne.com>
             To: humanmarkup-comment@lists.oasis-open.org, humanmarkup@lists.oasis-open.org
             Date: Fri, 13 Sep 2002 06:58:29 -0700

      Hi Everyone,



      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.


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

             From: "Bullard, Claude L (Len)" <clbullar@ingr.com>
             To: 'Rex Brooks'

             Date: Fri, 13 Sep 2002 09:09:12 -0500

      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.


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

             From: Rex Brooks <rexb@starbourne.com>
             To: "Bullard, Claude L (Len)" <clbullar@ingr.com>,'Rex Brooks'
             Date: Fri, 13 Sep 2002 08:14:37 -0700

      I don't have a problem with locators, and as I said, I am not
      suggesting deleting it. I just wanted to know what there is about it
      that is special to HumanML as opposed to the rest of the world or xml
      in general. I see your points, and I suspect that as we include it,
      it will eventually be included in some overall schema, perhaps the
      semiotics schema if such a thing comes about, or an ontological
      schema of basic concepts or constructs for an epistemological
      framework that clarifies how we describe general consensus reality.

      Also, it occurs to me that we may need to narrow object down for this
      case so that it is clearly a sign for a physical object, not a
      computer network conceptual object.


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

             From: Ranjeeth Kumar Thunga <rkthunga@interposting.com>
             To: humanmarkup-comment@lists.oasis-open.org, rexb@starboune.com,clbullar@ingr.com

             Date: Sun, 15 Sep 2002 15:05:02 -0400

      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

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

             From: "Bullard, Claude L (Len)" <clbullar@ingr.com>
             To: 'Rex Brooks'
             Date: Fri, 13 Sep 2002 13:01:41 -0500

      Here is an example of a data dictionary that has a
      geolocator system.


      Consider that you might get to such a site and then
      have to identify the locations of artifacts according
      to a local coordinate grid whose root is a geolocator
      but the rest of the grid is some set of xy or other
      location names.  For example, when describing the
      positions of artifacts, geological strata are used
      to date the artifact (the lower the layer, the
      older the artifact).  This works ok until one begins
      to dig in caves where higher and lower quit having
      the same correlation.

      We see in this sort of thing in
      public safety when one describes a road intersection,
      or some location relative to a named location.

      If we are strictly sticking to our charter, a locator
      has to have an effect on human communication for it
      to be in our scope.  I can make up some cases for that,
      but not today.


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

             From: "Bullard, Claude L (Len)" <clbullar@ingr.com>
             To: 'Ranjeeth Kumar Thunga'
             <rkthunga@interposting.com>,humanmarkup-comment@lists.oasis-open.org, rexb@starboune.com
             Date: Mon, 16 Sep 2002 09:09:35 -0500

      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.


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

             From: Rex Brooks <rexb@starbourne.com>
             To: "Bullard, Claude L (Len)" <clbullar@ingr.com>,'Ranjeeth Kumar Thunga'
             <rkthunga@interposting.com>,humanmarkup-comment@lists.oasis-open.org, rexb@starboune.com
             Date: Tue, 17 Sep 2002 06:50:27 -0700

      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

      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?


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

             From: "Bullard, Claude L (Len)" <clbullar@ingr.com>
             To: 'Rex Brooks' <rexb@starbourne.com>,'Ranjeeth Kumar Thunga'
             <rkthunga@interposting.com>,humanmarkup-comment@lists.oasis-open.org, rexb@starboune.com
             Date: Tue, 17 Sep 2002 09:06:13 -0500

      I vote for a combination of chronemic and a locator.
      That will map nicely to the way most software represents
      time and space data types.  The markup doesn't really
      care but the implementation code will.


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

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