Re: person location WRT position

Correct.

Carl

  ----- Original Message ----- 
  From: paola.dimaio@gmail.com 
  To: Carl Reed 
  Cc: C H ; Mandana Sotoodeh ; public-xg-eiif 
  Sent: Friday, September 12, 2008 12:00 AM
  Subject: Re: person location WRT position


  thanks Carl, v useful 
  so, would the following be correct:

  person/org has LOCATION (expressed as natural language words: name of city, street, postcode etc)
  (Location can have position, if we need to target with precision the location, say :-)
  resource has position (for logistic reasons)



  On Fri, Sep 12, 2008 at 2:04 AM, Carl Reed <creed@opengeospatial.org> wrote:

    A few emails ago I promised to provide clarification on the use of the terms "location" viz "position". Turns out that after reviewing the use of these terms in ISO, the OGC, and the IETF there appears to be consistency!

    ISO 19112
      location: identifiable geographic place

    ISO 19133
      position: data type that describes a point or geometry potentially occupied by an object or person

    The only real difference here is that position is defined specifically as a data type (or a representation), while location is "place".  This means that the two terms are often used interchangeably, very similarly to the dichotomy between "resource" and "representation" when speaking of ROA.

    The only distinction may be that "position" is restricted here to geometry (a point is a geometry, so the choice in the definition between the two is unneeded). So "the White House" is a location, but its position would have to be expressed as a geometry.

    ISO 19133 uses this distinction to expand the concept of "coordinate transformation" (which works on positions) to the concept of "location transformation" which includes stuff like geo-coding which transforms named places like "1600 Pennsylvania Avenue" into positions (so they can be mapped); and inverse geo-coding going from points on a map to addresses or place names.

    Raw tracking is position based (the phone's GPS sends coordinates, i.e. positions, in) but services (like navigation) do a lot of location transformations -- for example, putting addresses on map displays, or to answer question like "where am I?" which usually require a more human understandable expression than a lat-long. .

    Various IETF documents use the following: location information describes a physical position in the world that may correspond to the past, present, or future location of a person, event, or device.

    Almost identical. And all of the OGC location service standards use the same definitions.

    Hope this helps.

    Regards

    Carl


    ----- Original Message ----- From: "C H" <craighubleyca@yahoo.com>
    To: "Mandana Sotoodeh" <mandanas@ece.ubc.ca>; <paola.dimaio@gmail.com>
    Cc: "public-xg-eiif" <public-xg-eiif@w3.org>
    Sent: Wednesday, September 10, 2008 1:29 PM
    Subject: Re: person location





      I think this contact and location information is much more dynamic and it is very common to have to record complex instructions or complex paths through spacetime to be sure that someone can rendezvous with someone else in motion.  We can't assume that everyone everywhere has a satellite phone but nor can we assume that someone being moved by someone else doesn't ever need to be found en route (say for the delivery of some medicines not at the evacuation point that they nonetheless need before they get to the final destination).  "Bucket brigade" style transport where people or goods often move from one vehicle to another also requires very close coordination, but is extremely efficient in its use especially of special purpose vehicles or drivers who know certain terrain well.  So I think a deeper examination of how movement and contact between moving persons or goods is handled is required, with "details" and "status" needing depth.

      --- On Tue, 9/9/08, paola.dimaio@gmail.com <paola.dimaio@gmail.com> wrote:

        > - removed Population because it was originally there
        to show the beneficiary
        > of the services, now the two main agents in the model
        are Organization and
        > Person. If you think Population provides extra
        information, I'll add it on.
        >
        > - Person has a location and consequently its subtypes


      There's some value to having an abstraction to represent collectives or groups that are receiving services, but is "population" the right word?  I doubt it.  In some cases there may be a client_group or beneficiary_group designated to receive aid, if the word "population" is absolutely standard to mean small sub-groups, then fine use it, but I'd seek a more specific term.  I expect the term "population" to be a number of people living in a specific place, not a rich descriptor of a number of demographics and etc..


        > - contactDetails is still a separate concept, common
        between Person and
        > Organizations, because organizations might have
        general
        > contact information which is not linked to a Person or
        a Service.


      Of course it must be kept separate, but "details" may be a poor word internationally (not used in the US or Canadian English as in UK English). And there are different types of contact but of course those can be "detailed" as emergency_contact, UK_daytime_contact, fax_number, etc.. Frankly I'd rather see a very rich descriptor there containing a contact_protocol or contact_strategy or how_to_contact (could be a long list of strategies like "if it's daytime hours in the UK try reaching my secretary at 044... but if you know I'm in Kuala Lumpur... satellite phone number of my usual driver..." and perhaps at different security levels and constantly updated for close colleagues while strangers get only generic static published contact data.  A non-textual version of the how_to_contact instructions might eventually have to become standard, like a list of steps some of which can be automatically processed on a cell phone processor.

      Perhaps a first step could be to differentiate published_contact_details and private_contact_details, the latter containing any such rich instructions... ?


        > - added time-stamp and Status to Location (indicating
        whether the location
        > is valid, out of date, etc.),


      The system won't know this and generally won't be informed of anything except perhaps a verification at odd intervals that the location is valid *for now*.  So "status" might be a rich descriptor containing timeout and verification data ("Dr. Smith found Dr. Jones at this location but Jones indicated that he would be leaving it at noon for location X...") but in general this is only valuable if it points to a set of future locations (road to airport, airport to another airport, airport to hospital, etc.).

      So rather than time-stamping only the current location and having a messy "status", perhaps we must think of location itself as being a spatial location tied to a set of time spans, a data structure that looks like:

      - location now
      - location as of next known departure from location now / departure time
      - location as of next known departure from that location / departure time
      - location at which the individual will be located for forseeable future

      It's easy to see how this could fully and correctly describe, say, a person in the midst of a medical evacuation.  Requiring only one update for the structure, rather than an update to location every time they are moved...














  -- 
  Paola Di Maio 
  School of IT
  www.mfu.ac.th
  *********************************************