Re: person location WRT position

or maybe, in support of symmetry of representation,

resource has location/position  too


modeling challenges...?!


p

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

>  Correct.
>
> Carl
>
>
> ----- Original Message -----
> *From:* paola.dimaio@gmail.com
> *To:* Carl Reed <creed@opengeospatial.org>
> *Cc:* C H <craighubleyca@yahoo.com> ; Mandana Sotoodeh<mandanas@ece.ubc.ca>;
> public-xg-eiif <public-xg-eiif@w3.org>
> *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
> *********************************************
>
>


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

Received on Friday, 12 September 2008 15:41:38 UTC