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