humanmarkup message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: [humanmarkup] PBS-Doc-address
- From: Rex Brooks <rexb@starbourne.com>
- To: humanmarkup@lists.oasis-open.org, cognite@zianet.com, clbullar@ingr.com,kurt@kurtcagle.net, mbatsis@netsmart.g
- Date: Mon, 21 Oct 2002 07:00:59 -0700
Title: PBS-Doc-address
Hi Everyone,
Just so you know, this is the way I will be documenting the
Primary Base Schema as I go through it element by element. As you will
read, I have done some extra research here at the start in an effort
to be as thorough and up to date as we can be. And, sure enough, the
latest W3C proppsed recommendation for User-Agent Guidelines, with
which our specification will be most closely associated, btw, is dated
Oct. 16, 2002, the date of our last meeting.
A couple of things you might want to keep in mind are that except
for paenthetical notes, none of this material is new, and I am not
posting these compendia of messages for further comment now, but as an
easy way to document our work, so if you respond before the I submit
the final first working draft, you risk having your comments lost at
least on me, since I will have already moved on by the time you see
these posts. If I were you, I would just jot down your thoughts in a
running comments file until then.
Here is address:
(Editor's Note-1: Further research has
shown that we can import the namespaces for specifications with which
we need to be interoperable or specific elements or attributes from
those specifications in order to ensure that we are interoperable. I
do not propose to do exhaustive searches for every element but we know
that names and addresses will be universally important, so I have
worked on those to the extent that I have found three other sets of
specifications which deal with these elements, The OASIS Customer
Information Quality TC specificatins for Extensible Name Language and
Extensible Address Language, and the Extensible Names Services
Specifications from XNS.ORG/OneName Corp. I found numerous other
samples from W3C in particular:
http://www.w3.org/TR/P3P/#UserAgents
http://www.w3.org/TR/UAAG10/,
although for ISO documents, a charge must be paid, so I have deferred
searching that site in depth due to the fact that insufficient
information per document is available. )
(Editor's Note-2: The following message is an excerpt that contains
many references to artifacts as related to address, so it will be seen
again in that set of discussions. I shortened it as much as I could
without destroying the context. This last citation contains the most
relevant portions and some lesser portions of the preceding,
out-of-subject-line threads in which references to address and
artifact and the relationship between address and artifact)
Subject: Re: Base Schema-Address and Re: [humanmarkup-comment]
[humanmarkup TC]Assorted
meeting notes - from Rob
From: Rex Brooks <rexb@starbourne.com>
To: cognite@zianet.com, humanmarkup-comment@lists.oasis-open.org,Rob
Nixon <rnixon@qdyn.com>
Date: Mon, 20 May 2002 13:52:38 -0700
Hi, I thought I would acknowledge that
I received this and as with my
last previous reply to Len some hours
ago, I will have to get to this
tomorrow morning, although to be
honest, it will be more like Friday
morning. I don't know if it is my email
client, Eudora or my
settings, but I have trouble
understanding where each indent was
meant to be for organizational
purposes. So if it is possible to get
your work in an out-of-context word
processing file as an attachment,
it would help me. That way I would know
where you put the idents and
line breaks as opposed to where Eudora
put them. I could read it and
then put it back into context. If not,
I will just make do.
I remember way back when I was in
school, it seemed like I could
just blow through those insane reading
lists and it all just
magically stuck. Now I have to have my
mind clear and ready, then
carefully read through it all. Ponder
it, and boy am I ponderous
these days. Then I can discuss it.
I will catch up eventually.
Ciao,
Rex
At 1:56 PM -0600 5/20/02,
cognite@zianet.com wrote:
>Intro.
>
>Now the HumanML committee has moved
[from "phase 0", discussion] into
>the stage of actual schema design
for HumanML.
>
>Thus saith Rob Nixon:
>
>At 11:38 AM 19-05-2002 -0500, you
wrote:
>>Hello everyone, sorry for the
delay.
>>
>>Here are a few notes related to
the discussion we had during our monthly
>>HumanML Technical Committee
conference call on the 15th. Many of these
>...>speak in the
>>languages of physics,
mathematics, and systems sciences,
>...
>> also overlaps with the
concepts underlying the semantic web approach.
>>
>>These notes are not meant to
send us wildly off course, but rather to
>>make sure that we have explored
our assumptions.
>>
>>1). ARTIFACTS:
>>
>... [marvelous exposition, q.v.,
referred to in part below]....
>
>Per Rex Brooks and Ranjeeth
Thunga's guidance, we've begun jointly
>re-working through the caderie of
possible terms for HumanML. Today in
>our conferenced telephone meeting
note was taken that since our problem
>is handling the "human"
which is invariably also contextual, a shallow
>list of terms such as suitable for
some other markup endeavors is
>patently insufficient. How, then,
to proceed to bring contextualization
>into our base of primaries (cf.
primitives)?
>
>The following analysis of the first
term under discussion, ADDRESS, sets
>it up as RELATIONAL, with CONTEXT
CONDITIONS.
>
>It turns out to be amazingly
consonant with Rob Nixon's concurrent
>discussion of the second term,
ARTIFACT.
>
>Rob's point j) describes how an
ARTIFACT is "manufactured" ... "out of
>the knowledge and information field
of the individual or the group". His
>points g) and h), speaking of
'trajectories' zooming "through the
>knowledge and experience 'space' of
the individual perceiver" [who is,
>themself,] "a node in a
cultural and social network...with (feedback
>loops) interconnecting the artifact
nodes and beliefs) among the
>interacting individuals"
propose the interesting idea of "momentum"
>within a dynamic net.
>
>When an ADDRESS is a special case
of an ARTIFACT, as I'd opined in our
>phone meeting, Rob's description of
ARTIFACTs in terms of nets are thus
>illustrated by the concrete
"semantic-net-portions" for ADDRESS set out
>below. Elaboration on
contextualizable nets follows, and then some
>questions to work from.
>
>
>comments re humanML base schema
term or "region" of meaning:
>
>
c. by author: S. Candelaria de Ram, 15 May
>2002
>--------------------
>contents:
>
0. Intro
> dialog, point of departure
> TOC
> bridge
>
I. analysis for ADDRESS, working term currently under discussion
> working notes
>
REF, sample current apps' "address records"
>
>convention for expressing context
in [processing] rule by using x
>----/C ----> y
>
>
generalities extracted
>
>contact method ---/situational
conditioning
>---> contact location
specifier(s)
>
>referror [signifior] ----/situation
including current ROLES
>----> reference NAME(s) or
DESCRIPTION(s) [sign/symbol] [of REFERENT,
>signifie']
>
>
discussion points, A B C
>
pan-culture
> agency
of processes
> ADDRESS
as special case of next term ARTIFACT
>
II. general theory for implementation (of contextualized
>relational nets)
> approach background, dependency
graphs
> REFs, hetnets, ghetnets [grounded]
heterogeneous
>nets, v.
semantic nets
>
III. Schema Design, development questions, A - H...
> (nature and interrelation of HumanML
PRIMARIES and SECONDARIES;
> ancillaries;
uniformity/content-direction issues)
>
>--------------------
>
>The following analysis is open for
plenty of discussion. The questions
>in the last section particularly
are directed toward large-scope issues
>of design for making a COHERENT
SCHEME.
>
>================
>I. analysis for ADDRESS, working
term currently under discussion
>
>working notes:
>
>
REFERENCE for comparisons: Dan Conolly's
>
www.w3.org/2000/10/swap/pim/contact.n3
>
which discusses MS vcard, MSOutlookContacts.n3, q.v.
>
>
convention: / for in-condition-of or CONTEXT specification,
as
> used in linguistic rules like
this:
>
PRONOUN.demonstrative --> these / near & plural
>
> this /
near & singular
>
> those / far & plural
>
> that / far & singular
> These conditionals may be formulated
alternatively,
>for instance
> as logic rules or equivalently as
nodes/links in a
>reasoner net..
>
>
>
generalities extracted:
>
> contact method ---/situational
conditioning --->
>contact location specifier(s)
>
>
e.g., computer browser ---/connectivity etc.
>...---> website address
>
>
as domain name or IP number and optional directory location
> Note
implicit action from computers
>on both sides.
>
e.g., postal mail ----/situational
>conditioning ----> postal
address
> Note
implicit actions from matrix
>culture and service agents on both
sides;
>
multiple postal addresses (office,
>home, vacation home) and
contact
>methods usable for
>
different times, relations between
>communicants (interlocutors).
>
e.g., shank's mares ----/situational
>conditioning ---->
geophysical
>access provisions and landmarks
> Note
relevance in some conditions,
>agency involved both sides.
>
> referror [signifior] ----/situation
including current
>ROLES ---->
>reference NAME(s) or DESCRIPTION(s)
[sign/symbol] [of REFERENT, signifie']
>
>
e.g., names such as first-name, ..., last-name
>
e.g., role names such as Mom, Sir
>
e.g., email alias
>
>
discussion points:
>
>A. The
generalities might be treated as PRIMARY/BASE/1o terms. They are
>pretty much
>pan-culture.
>
>The examples given (with
"e.g.,") are specific to certain situations
>of use or application.
Logically, that would push them to SECONDARY,
>application-specific -- or maybe
[partially] SHARED-by-secondaries?
>(Cf. the shared portions of gcc and
other software suites.)
>
>
>B. Process
is involved in utilizing ADDRESS; application for communication
>therefore renders it neither solely
noun nor verb. Whereas a node alone
>is non-relational, THESE
DESCRIPTIONS ARE RELATIONAL, AND
>CONTEXT-CONDITIONED. The
"contact location" portion is the ADDRESS.
>AGENCY is implicit in its
functional significance. An ADDRESS can't be
>an address unless it is interpreted
in real-world activity (NB
>logicians) as a location for
contacting [somebody]. Process in this case
>requires agency.
>
>Is it correct that mutuality enters
in here in all cases, or not?
Subject: Re: [humanmarkup-comment] Base Schema-artifact
From: Rob Nixon <rnixon@qdyn.com>
To: "Bullard, Claude L (Len)" <clbullar@ingr.com>
Date: Tue, 21 May 2002 10:07:20 -0500
Thanks Len,
I understand your point in regards to
the Base Schema and agree that "Thinging" things can lead to
a
Pandora's Box (whether it is for good
or ill). My intention was to explore whether or not the
assumptions
that we are working under have any
holes in them up front, it is not to send us off into the Twightlight
Zone
when we have serious work to do.
I will however, continue to bang into the walls as we go in an effort
to
find "rotten wood".
Thanks,
Rob
<snip-artifact-related material>
>Regarding:
>
>2. ADDRESSES ( as well as many
other attributes )
>
>We must allow for multiple
concurrent addresses, as well as a historical
>list or tree of address ( again as
we move forward and backward ) in time
>related to VR simulations (leaving
out our non-linear time effects
>previously discussed).
>
>Again, these are all only points to
consider.
>
>Rob
Subject: RE: [humanmarkup-comment] Base Schema-address
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
Date: Mon, 13 May 2002 14:26:21 -0700
Yep.
The forgetting part is one of the
things we need to keep in mind, and
not just us, of course. Very
non-trivial. I won't go into my diatribe
about the need for a new transport
protocol. I'm hoping XMLP will be
it, but it isn't looking very hopeful
right now. Have you read their
requirements? At least I know where to
get a kitchen sink that isn't
a kitchen sink until I want it to be a
kitchen sink.
When I think about this stuff, I start
getting a headache. I have had
a lot of headaches recently. I really
wish some of those folks on
xml-dev were in the WSIA TC.
It is especially important for folks
here to note that address is an
association not a property.
<kidding>I think I will go have
my headache now. </kidding>
Ciao,
Rex
Subject: RE: [humanmarkup-comment] Base Schema-address
From: Rex Brooks <rexb@starbourne.com>
To: paul <beadmaster@ontologystream.com>,
humanmarkup@lists.oasis-open.org,humanmarkup-comment@lists.oasis-open.org, Rex Brooks
<rexb@starbourne.com>
Date: Mon, 13 May 2002 14:06:55 -0700
Thanks, Paul,
I agree, creating a set of classes is
just another step down the
road. I didn't suggest it as an end, I
was only pointing out that for
general programming purposes, such as
fundamental interoperability
and agreement between various
vocabularies, and object processing
across the web/net, building such a set
of classes, very carefully,
is, IMO, inevitable.
As far as the AI issue is concerned, we
have a subcommittee that is
exploring that, and while I have my own
thoughts on the subject I am
satisfied to let that develop within
that subcommittee.
I don't think this thread is
appropriate to speak to that issue. In
this context, what we are doing now is
going through our Base Primary
Human Markup Language XML Schema item
by item to examine it
thoroughly and methodically. The AI-VR
Subcommittee is concerned with
this process as are all currently
envisioned extensions, or secondary
schemata, as we have termed them. The
Base Schema needs to contain
the elements upon which these
extensions can be built.
So the work of deriving and harmonizing
classes for OO programming
purposes is not likely to begin in
earnest until after the Base
Primary and subsequent Secondary
Schemata have been written,
discussed, and submitted to OASIS as
Recommendations. And then it may
well be that
the task itself will be more in the nature of
harmonizing between and amongst the
variety of applications that
hopefully will have been developed as
implementations by then. I can
vouch for at least two such
applications myself: a middleware
movement and gesture language to drive
the H-Anim Specification of
the upcoming X3D specification which
will provide for standard bodily
and facial gestures for 3D
representations of humans; and a
meeting/presentation audience
monitoring or collaborating tool that
generates and presents reports that use
HumanMarkup in addition to
other more standard toolsets.
We have subcommittees for Physical
Characteristics Descriptions and
Diplomatic Communications as well as
AI-VR, so it is likely to be
quite a while before we can truly
address the topics you are
suggesting.
By then, perhaps, such technologies as
you are working toward may be
able to adapt our work, or, perhaps, a
Stratified, Adaptive Human
Markup Language could be developed.
However, if it is possible to
extrapolate what a Stratified, Adaptive
Human Markup Language might
require, it would be wise of us to make
an accommodation to allow it
to be more easily developed. However,
for now, we need to be as
concrete and immediately useful as we
can in order to garner
acceptance and support. Our success
depends on it.
Being mindful of concerns which may
become desireable or necessary is
a good idea, too.
Ciao,
Rex
Subject: RE: [humanmarkup-comment] Base Schema-address
From: "Bullard, Claude L (Len)"
<clbullar@ingr.com>
To: 'Rex Brooks' <rexb@starbourne.com>,
humanmarkup-comment@lists.oasis-open.org
Date: Mon, 13 May 2002 15:24:44 -0500
An address as a very abstract class
might include
email addresses and physical location
addresses.
However, a physical location address
can have
different naming systems so to make
these concrete,
it is usually prudent to have a
geo-location
system as the actual physical address.
Then the
naming location systems (eg, city,
state, county,
country, parish, etc.) can be codes.
For HumanMarkup,
an address must be internationalizable,
so we
may need a more complex type
here. British
home addresses and American home
addresses don't
always have a lot in common. Any
suggestions?
An email address is a different
beastie. It gets
its mapping from the Internet Domain
Naming System.
As such, the string property can easily
be described as
a type using a regex, but it can't be
tied to the
DNS except by system assignment.
In the context of a humlIdentifier,
these are properties
associated to the human, not properties
of the human.
BTW: because humans move around a
lot, history records
are often kept and require a purge
policy (it is important
to forget as much as it is to
remember).
len
Subject: RE: [humanmarkup-comment] Base Schema-address
From: paul <beadmaster@ontologystream.com>
To: humanmarkup@lists.oasis-open.org,
humanmarkup-comment@lists.oasis-open.org,Rex Brooks
<rexb@starbourne.com>
Date: Mon, 13 May 2002 16:03:56 -0400
Ultimately agreeing to a set of classes
is not the eventual state of
intellectual evolution. It is in
fact an illusion. Object-Classes are
useful as a way of boot strapping into
the organization of process flow and
data realization. However, once
we accept this bootstrap as the final goal,
we lock ourselves into a strict
reductionism and is often seen as the AI
Dream (that a machine can think).
This is not appropriate for human markup.
However, there is some good work by
Tonfoni
http://www.bcngroup.org/area3/gtonfoni/tonfoni.htm
that I wonder if the members of the
human markup committee are aware of.
It may be ok in technology communities
to banter around this AI Dream as if
the
dream
1) is a reality
and
2) is a desirable end state to the
evolution of intelligence
However, the natural science community
is becoming more and more unhappy
with this Dream.
Other standards communities (Topic Maps
for example) have already
experienced the go around on this
issue, and may wish to think that issues
like scope are being addressed in a
profound and completely fulfilling
fashion. But scope, like context
is not so easy to reduce to an exact and
precise ontology.
New intellectual machinery is needed,
and part of this has to do with the
non-reducibility of intelligence to
algorithms and exact specification.
I will discuss some of the issues
regarding this, if there is interest. My
comment is not made as a personal
insult or an attack on anyone... however
there is a principled argument that
scope, viewpoint and context require an
extension of the Complex Adaptive
Systems thinking to what is called
Stratified Complexity.
http://www.bcngroup.org/area3/pprueitt/book.htm
Paul Prueitt
Subject: [humanmarkup-comment] Base Schema-address
From: Rex Brooks <rexb@starbourne.com>
To: humanmarkup-comment@lists.oasis-open.org,
humanmarkup@lists.oasis-open.org
Date: Mon, 13 May 2002 08:26:41 -0700
Hi Everyone,
Please keep these threads within the
Subject Line that initiates
them, for easier reference. The
elements are arranged in alphabetical
order and this seems like the most
sensible way to organize it. I
will follow that organization in
discussing them.
It has the value of being accepted as
not implying any kind of
hierarchical or other classification
system. As someone joined at the
hip to OO, it also makes it easier for
me to remember that we are not
creating classes, yet. I add the yet
because at some point, once we
start building applications, we will,
of necessity be brought to the
task of agreeing upon a set of classes,
but that is so far downstream
from this point in our development that
it need not concern us
greatly.
I will go through them, as nearly as
possible in the order they
appear: element definitions first,
global attributes and then
datatypes.
Even as we go through this exercise, it
is certain that we will
develop new elements as they occur to
us and as the subcommittees
begin to identify the elements they
will be needing, but I think it
will be easier to spin those
discussions off into separate threads,
for which I suggest we use a variation
of this Subject line, thus:
New Base Schema Element-element
name.
That said, our first element:
address
This is a Complex Type and it is
specified as a named address system
such as street, city, state, etc. It is
noted that when this element
is used it will be code-based, i.e. an
instance of an accepted,
existing, named addressing system in
international use.
It is further specified that is a
member of the xsd:attributeGroup
referenced by
"humlIdentifierAtts"
Because it is a variable value that
will change over time, it is not
a Global Attribute.
All of that is fairly straightforward
and I doubt anyone can have
much concern about it, however, what
occurs to me is the question of
whether we might want to distinguish
between residential addresses,
postal addresses and email addresses,
although email is a bit of an
orange in this box of apples, so to
speak. However, for the purpose
of sending communications or freight,
and tracking such things for
double checking accuracy, for instance
in the case of multiple
individuals sharing the same name, it
might be good to have these
distinctions under different elements,
or additional attributes
within this element.
Okay, we have a number of ways in which
this element can be used. And
these ways also come into play in how
we structure this element. I
can think of
several scenarios where the distinctions I mentioned
above will be of vital importance:
Scenario 1: Emergency Services Delivery
in a natural disaster, where
two Joe Smiths live in the same town
where a tornado has struck and
both have special medical needs that
need to be taken into account in
case they require emergency medical
care on the scene of the
disaster. Both have verifiable internet
identities, email addresses,
etc. Can address information help?
Secnario 2: Joe Smith, tenant at 12345
Mill Rd, Oceanview, New Jersey
receives mail for a former tenant, and
it appears to be an important
and time-critical piece of information.
All he has is a name. Is
there a chance that he can get the
correct address in a secure way
that does not tell the wrong person
what kind of information he is
seeking to redirect to its proper
recipient?
I will leave it at two scenarios. I
have used examples here that I
have had actual experience with in my
own life except that I simply
added a second person with the same
name for a scenario 1 based on an
incident where my neighbor had an
asthma emergency, and the neighbors
did not know he had asthma, only that
he was apparently unable to
breathe. It turns out that I later
developed a kind of asthma myself,
fortunately not triggered by stress
like his, but emergencies can
easily trigger this kind of subsequent
problem. I have also received
mail for at least two other Rex Brooks
and you might call that a bit
unusual, so I also know that these
kinds of situations can occur. For
more common names, I am sure this kind
of thing is not really unusual
at all.
So, this is what I intend to do as I go
through the elements in the
HumanML Schema Len diligently worked up
for us in Phase 0.
I will try to do at least 3 a week,
rather than one a day, though
even that may be optimistic.
Ciao,
Rex
--
--
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