- From: <paola.dimaio@gmail.com>
- Date: Fri, 12 Sep 2008 08:41:02 -0700
- To: "Carl Reed" <creed@opengeospatial.org>
- Cc: public-xg-eiif <public-xg-eiif@w3.org>
- Message-ID: <c09b00eb0809120841j211ea445x12768f5cc70ed836@mail.gmail.com>
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