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

Received on Wednesday, 10 September 2008 19:30:21 UTC