Fwd: EIIF draft needs unified person, rigorous when/where, criteria towards common ontology, use of phases

Thanks Gavin
but

is the ISO vocabulary available for web access and public reference?
if not, that would mean reference only indirectly, wouldn't it?

pdm


On Tue, Nov 25, 2008 at 10:18 AM, Gavin Treadgold <gt@kestrel.co.nz> wrote:

>
> I flagged ISO 8601:2004 in the initial standards review in the wiki a long
> time back. If it isn't in the report, someone has probably overlooked this
> existing standard and it should be added.
>
> <http://www.w3.org/2005/Incubator/eiif/wiki/EMInfoStdsReview>
>
> Cheers Gav
>
>
> On 2008-11-25, at 1245, Carl Reed wrote:
>
>  And on the "when" I checked the W3C OWL-time recommendations (at least the
>> one document you referenced). No mention of
>> ISO 8601:2004, Data elements and interchange formats — Information
>> interchange Representation of dates and times
>>
>> Do you know if this document was considered (or not?). If not, why. Reason
>> I ask is that OGC, ISO, IETF, and OMA standards all use ISO representation.
>> As long is there is no information model difference, then interoperability
>> should not be compromised. Otherwise, there could be issues in terms of the
>> movement of data in a workflow, such as get an observation from sensor,
>> process the observation, provide an alert and then generate a route.
>> Different standards used through the workflow.
>>
>> Just wondering.
>>
>> Thanks
>>
>> Carl
>>
>>
>> ----- Original Message -----
>> From: "C H" <craighubleyca@yahoo.com>
>> To: "public-xg-eiif" <public-xg-eiif@w3.org>
>> Sent: Saturday, November 22, 2008 11:33 AM
>> Subject: EIIF draft needs unified person, rigorous when/where, criteria
>> towards common ontology, use of phases
>>
>> >
>> > My quick comments on the draft, to be followed up later, as there's no
>> teleconference now until January.
>> >
>> > 1. person
>> >
>> > There should be only one "person" object and attributes of persons
>> should be attributes of that object, that is, the impact /affect of a
>> disaster can be a different type of object  "emergency_affect' (or in the
>> very sad unreadable non-English idiom W3 uses, emergencyAffect).  A list of
>> those can be attached to a person, with the potential to model several
>> different emergencies and affects, or the status of a person as both
>> affected and assisting without a multiplicity of objects.  Proliferating
>> entities is a bad idea at the best of times.  Certainly having to destroy an
>> object and create another one when a person changes status, or moves from
>> being potentially to really affected, adds a lot of potential for error.
>> >
>> > Consider also the example of a doctor displaced by a flood, who is
>> assisting in a hospital in an evacuation camp.  This person is affected by
>> the flood, potentially affected by any epidemic that spreads in wake of the
>> flood, and assisting with the medical activities that help prevent that
>> epidemic or treat its victims.  There's a long list of emergencies at
>> various phases (per the model) that this person is involved in, and ways
>> they're involved.  Imagine now also that some of their family members are
>> missing.  You can start to see how truly bad an idea it is to be creating a
>> new variant of the person object for each affect, and to try to manage them
>> without one way to attach all these attributes to a unique person object.
>>  There are privacy reasons to avoid combining data but this can be dealt
>> with by making attributes encodable in such a way that one can only check
>> existence of an affect in a given context, and only if that exists would the
>> data be
>> > decoded/retrieved.
>> >
>> > 2. when and where
>> >
>> > The OWL-time recommendations already mentioned
>> http://www.w3.org/TR/owl-time/
>> > are competent enough to use for this application, in my opinion.  They
>> call a TimeSpan an "Interval" and one that is relative (unfixed in time with
>> a moving starting point) a "Duration" and even have specialized concepts
>> like "DeliveryDuration" which are useful out of the box.  Unlike incompetent
>> time libraries this one actually has understood that dates and years and
>> such cannot exist without a specified time zone (an amazingly common error
>> that destroys the integrity of any time library that so much as permits
>> dates to be specified w/o zones).
>> >
>> > Accordingly this terminology should be the default.  The "trajectory" is
>> also absolutely necessary and I'm glad to see it, because it allows some
>> degree of interception of resources in flight, optimization of deliveries
>> and so on.  But I think the word is "itinerary" in most libraries, a
>> "trajectory" sort of implies the actual path taken not an intended path.
>>  The way I see this working in practice is that GPS reports update the
>> actual location and then some subsystem can calculate the expected times of
>> arrival, reschedule rendezvous, etc. to really minimize waiting and update
>> the expected times to travel specific routes (due to new potholes, snipers,
>> etc.).
>> >
>> > 3. towards common ontology
>> >
>> > This section isn't of much use without a list of questions that can be
>> asked of ontologies that are being considered for convergence.  For
>> instance, we can ask "is it easy to map this interoperability framework onto
>> [this other ontology] or is it really necessary to converge semantics and
>> align the terminology exactly with it?"
>> >
>> > I would argue, for instance, that you must align date/time/place
>> terminology with other libraries and cannot "map" them because the possible
>> semantic errors are vast in number and no value is added by the mapping.
>>  Also it has to happen in potentially thousands of places in the code.
>> >
>> > However, it seems inevitable that medical records of a person would be
>> mapped onto the EIIF definition of a person, if only because privacy
>> concerns forbid the EIIF users having all the medical records of everyone in
>> the same database or forcing a standard encryption method on every medical
>> service provider.
>> >
>> > I would like to see this section evolve into a list of related
>> ontologies and a one-line description of how well or how deeply each could
>> or should converge/change or provide precedents for EIIF to copy more
>> exactly in future releases.
>> >
>> > 4. phases
>> >
>> > Defining the phases is a real contribution but the text seems to present
>> the concept a bit too monolithically.
>> >
>> > It needs to be clearer, perhaps with an example, that several
>> overlapping emergencies (like a flood and subsequent water shortage or
>> epidemic) often occur - and that the phase diagram is more useful to
>> calculate the kinds of transactions that will tend to overload the systems
>> at particular times.  Allowing resources to be staged.  For instance, if you
>> know medical services will be needed particularly badly in the immediate
>> wake of an earthquake, but that floods tend to have a longer and more
>> profound effect on health due to bacterial contamination of water supplies,
>> you may be able to schedule the types of medical supplies and personnel more
>> readily.  It should be possible to build a model of what emergefncies, major
>> and minor, tend to co-occur and follow on one another, e.g. total power
>> blackout tends to lead to looting opportunities and armed conflicts, in any
>> particular place and keep updating that model based on actual experience in
>> similar cultural
>> > settings.
>> >
>> > The word "resilience" belongs in there more prominently, perhaps as a
>> function of response effectiveness in all the phases.  One might say, for
>> instance, that resilience is calculated by multiplying the effectiveness
>> across all phases, however weighted, and accordingly that you can't achieve
>> resilience by neglecting any phase - are better off shoring up weak points
>> rather than trying to become "best in the world" at some more visible phase.
>> >
>> >
>> >
>> >
>>
>
>
>


-- 
Paola Di Maio
School of IT
MFU.ac.th
*********************************************




-- 
Paola Di Maio
School of IT
MFU.ac.th
*********************************************