[topicmaps-comment] RE: [humanmarkup-comment] Base Schema-address

[paul <beadmaster@ontologystream.com>]

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




-----Original Message-----
From: Rex Brooks [mailto:rexb@starbourne.com]
Sent: Monday, May 13, 2002 11:27 AM
To: humanmarkup-comment@lists.oasis-open.org;
humanmarkup@lists.oasis-open.org
Subject: [humanmarkup-comment] Base Schema-address


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

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>