[humanmarkup] PBS-Doc-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

humanmarkup message