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

Gavin

are we referring using only the ISO naming for timestamps, or are we
referring to
ISO EM terminology/glossary (sorry if I missed some references)

for abiding to an ISO convention does not require an ISO license, especially
just a small fragment (can be considered as 'de facto' standard) however, to
explicity reproduce an entire ISO glossary would do so


http://www.xml.com/pub/a/2003/09/24/deviant.html


I the latter case, I think we should seek guidance from W3C, (Renato, can
you ask?)


On Wed, Dec 3, 2008 at 5:45 AM, Gavin Treadgold <gt@kestrel.co.nz> wrote:

> Hi Paola,
>
> I believe it is 'public-enough' to not be an issue. Google for ISO 8601 and
> these references come up, including a document on w3.org.
>
> <http://www.w3.org/TR/NOTE-datetime>
> <http://en.wikipedia.org/wiki/ISO_8601>
> <http://www.cl.cam.ac.uk/~mgk25/iso-time.html<http://www.cl.cam.ac.uk/%7Emgk25/iso-time.html>
> >
>
> There is certainly more than enough information for implementation,
> although I don't know if this is to the level of openness that you would
> require.
>
> Cheers Gavin
>
>
>
> On 2008-12-03, at 0707, paola.dimaio@gmail.com wrote:
>
>
>
>
> 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
> *********************************************
>
>
>


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