Re: person location

Mandana, I like the changes, thanks a lot

we may still need to do a bit more refinement as we figure things out

would geocode correspond to what carl is describing as position, if so,
should we call it position and place it close to
location (posiiton being a subset of location)

a few other things may require a verbal explanation so that we can
understand better what we mean

as soon as we are ready, we can start attaching definitions to the words
used therein, therefore producing our first
vocabulary for this exercise, I think

In fact, as we come up with standard definitions (such as the ones provided
by karl) would it be a good idea to stickem
on the wiki?
http://www.w3.org/2005/Incubator/eiif/wiki/Controlled_Vocabulary_Page


I opened a page which is still a bit rough, Carl do you have a link (source)
for the definitons that you provided so that we can document the process?


:-)

Craig



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


what you say here, and below, is possibly true. i think 'semas, ntic
precision' is important, and we should strive for it
The challenge is to maintain precision without becoming too narrow in our
representation

So for details, status, location before/during/after, we hopefully will find
the appropriate level of granularity fo these definitions as we apply the
model - our model can even be used as an guiding principle, so I can
envisage an implementation would hav e higher granularity (different types
of location), but I would be satisfied if we came up
with a schema that has 'location' in it, then anyone can specify the
location in more or less detial as they require


p



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