[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [humanmarkup] RE: PBS-Doc-locator(commentary)
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.
http://pajis.lasd.org/XML
http://pajis.lasd.org/XML/IncidentReport/Sep2002/IncidentReport.xsd
John
-----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.Ciao,RexAt 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.
len
-----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,
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.
Ciao,
Rex
--
Subject: RE: [humanmarkup-comment] Base Schema - locator
From: "Bullard, Claude L (Len)" <clbullar@ingr.com>
To: 'Rex Brooks'
<rexb@starbourne.com>,"'humanmarkup-comment@lists.oasis-open.org'"<humanmarkup-comment@lists.oasis-open.org>
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.
len
Subject: RE: [humanmarkup-comment] Base Schema - locator
From: Rex Brooks <rexb@starbourne.com>
To: "Bullard, Claude L (Len)" <clbullar@ingr.com>,'Rex Brooks'
<rexb@starbourne.com>,"'humanmarkup-comment@lists.oasis-open.org'"<humanmarkup-comment@lists.oasis-open.org>
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.
Ciao,
Rex
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'
<rexb@starbourne.com>,"'humanmarkup-comment@lists.oasis-open.org'"<humanmarkup-comment@lists.oasis-open.org>
Date: Fri, 13 Sep 2002 13:01:41 -0500
Here is an example of a data dictionary that has a
geolocator system.
http://www.chin.gc.ca/Artefacts/RULA/e_sample.html
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 thepositions 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.
len
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.
len
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
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
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.
len
--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