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

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

Received on Tuesday, 25 November 2008 03:19:48 UTC