[humanmarkup] Base Schema-address

[Rex Brooks <rexb@starbourne.com>]

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