Re: time-stamping any location, flagging how it was inferred/assumed/reported [was] Re: person location vs position

Thanks Craig

I fully agree on the timestamp requirement (location, timestamp)
that would come under meta-meta data perhaps
then again it makes me wonder what other data field need timestamp, or
should there be a timestamp for the record  itself, other than a
timestamp for individual  fields/elements of the schema?

re. location/position, I just realised that in my posts I used them as
synonyms, when they may not be - so whatever term we chose we should
define it, qualify it and stick to it (talking to myself here)

re assumptions: we may have affectedPerson  with no devices at
all,whose location is reported verbally by others,  we may also have
people whose basic info is missing -

cheers
PDM


On Sat, Sep 6, 2008 at 7:49 AM, C H <craighubleyca@yahoo.com> wrote:
> In practice I'm sure most location information will be inferred from reports or requests, or gathered from GPS in vehicles or phones.  I can't see busy EM personnel typing in coordinates or trying to describe where they are every ten minutes ("yes I'm still here").
>
> Paola suggests:
>> Maybe you are trying to point to distinction
>>
>> location = static
>> position = dynamic
>>
>> so maybe both fields are useful in determining where an
>> affectedPerson is when they need ES?
>
> Use of "location" to mean "static" and "position" to mean dynamic is very non-obvious.  Isn't it more standard to use terms like "last_known_location" and "usual_work_hours_location" so that anyone can understand what's meant?
>
> The distinction I want to make is how stale or reliable or static is the information, and how it was derived in the first place.  For instance any vehicle location cached more than a few minutes ago is probably stale, though victim locations may not change so fast unless they're being transported (e.g. in a vehicle)... A system that caches a lot of locations while in sporadic contact with say a WiMax network set up in the emergency zone will cache many stale locations and will preferentially update only those few required for its work when it receives a signal again.  So we must assume, I think, that databases of locations will always contain many stale and static assertions that potentially can be updated and verified by any other field personnel as part of any other report or response.  For instance, a system could infer from a request to evacuate injured persons coming from Doctor Jones that Doctor Jones was at that location with them, unless
>  otherwise informed.  Tags and flags to indicate such assumptions or at least how the system had inferred the locations of persons would be advisable, or at least allow for such tags and flags to evolve over time.
>
> Graphically there are many examples, particularly in the ACM CHI and CSCW conference literature, of signalling the age or reliability of information using color or translucency.  Some of these methods are extremely reliable and match well with human cognitive biases.  Some work well for audio too.  Imagine if the less reliable information, when retrieved verbally, was actually transmitted at a lower volume, so that a user would be less certain to believe they'd heard it - if they say "what?" or "where?" that triggers an automatic update process.  Simulating, in effect, a softer echo from data further back in time.  Alternatively, prefacing such data with disclaimers "last known location...", "from last request for help we assume location...", etc., could be effective with sufficient data tagging.
>
> I had said:
>> >> These are recognizably a physical location on the
>> Earth with coordinates but are also clearly distinguished
>> from the actual physical location of the person, body or
>> vehicle.  Which we must assume the system will know.
>> >
>> > no Craig, we must avoid making assumption. the system
>> might be down at
>> > any given moment, and person may be able
>> > to give position using natural language or approximate
>> location etc
>
> Agreed.  Hopefully I have dealt with these issues above.  I qualify accordingly my last sentence as "Which we must assume the system will have the potential to know, whether or not the standard form of coordinates is expressed in that field and whether or not the last update has been recent enough to be sure of finding them at that location and whether or not we have tags or flags to indicate how the location was inferred or assumed, and whether or not the user interface conveys any of this to the user(s)."
>
> So, to keep things simple, I suggest we at least need a time-stamp on any location, with perhaps some flag to indicate that the location is static or stale and not being updated by any automatic tracking system.  The option of giving a location (I don't see why a different word ought to be used) in natural language, is fine if actual GPS coordinates don't exist.
>
> Carl kindly inforkms me that "in OGC standards land, "location" includes both static, dynamic location, location by reference and so on" and OGC has "MovingObject elements in GML (used in NIEM 2.0) and the Tracking Service interface standard for use in Location Services. Also, the work being done in the US Next Generation 9-1-1 activity has a major requirement to deal with mobile and location enabled IP devices."  So I suspect the issue has been dealt with adequately in those designs and we should investigate that before inventing new meanings for "position" (very overloaded term already).
>
> Craig
>
>
>
>



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

Received on Saturday, 6 September 2008 15:27:53 UTC