RE: [humanmarkup-comment] Base Schema-address

[Rex Brooks <rexb@starbourne.com>]

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

At 3:24 PM -0500 5/13/02, Bullard, Claude L (Len) wrote:
>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
>
>-----Original Message-----
>From: Rex Brooks [mailto:rexb@starbourne.com]
>Sent: Monday, May 13, 2002 10: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>
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>


--