OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [emergency] Info Model 2005-06-20 (GIS comments)


Folks,

This is meant to be a summary of what I was trying to say during today's
GIS subcommittee meeting.  The basic gist is that, because of the EDXL
Distribution Element's information structure, we can have our cake and
eat it too.  Basic suggestions:
1.  Leave CAP alone for now with repect to WGS 84 and its Area
structure.  It is gaining traction and changing it now would cause
enough loss of momentum that the whole effort at EM standards could be
hurt.
2.  That said, we must address the issues of GML and difference in
representation, as it applies to the distribution element, and
distribution content (to include CAP).  This can be done by recognizing
and using the information structure of the distribution element. 
3. The "targetArea" of the element is designed to carry only the
"boundary of interest" for the enclosed messages.  As such it must be
simple, flat, and quick to process by intermediate processes (e.g.,
message brokers) that may not even try to process the details of the
message content.  While we agree that GML is an excellent standard and
highly appropriate for geographic information, we have not yet seen the
particular set of simple GML geometries that meet the needs of
targetArea.  But we will. Carl has promised to provide. Once evaluated,
it is probable that a simple GML boundary representaion for polygon and
circle will be approved for the EDXL distribution Area block.  (We may
also consider this structure for CAP, but not until version 2.0).
4. There will be a need for the transmission of more complex (or just
different) geographic elements in context with a CAP message or with
other messages using EDXL Distribution.  In such cases that content can
be added as one or more additional Content Messages under a single the
EDXL Distribution Element.  XML content will follow the rules of the XML
Object which allow embedded constructs using other referenceable
standards or named structures to be included with the larger message.
In ths way SensorXML, IEE 1512, CAP, GJXDM and other content can be
combined for transmission without losing native format.  Non-XML content
content will follow the rules of the Content Object structure allowing
for embedding objects using MIME type or referencing the location of
external objects for separate retreival. 

KEY CONCEPT: Content Messages will follow their own referenceable
standard (open or proprietary).  Distribution engines will not be
required to understand the rules of Content Objects, but recipients will
be expected to 1) determine if they can process content and 2) process
what they can.  This encapsualtion of content makes it easier to manage
a distribution engine without limiting the content it can process.
(Content-based distribution engines will have two ways to deal with
their issues: process the content-oriented keywords in the distribution
element and/or 2) read and process the content of thoes Content Messages
that they understand while ignoring those that they do not understand.)

Still under consideration might be a standard response from a recipient
unable to read content back to its originator. (I do not know if this
would even be a requirement, but it might for certain specialized use
cases.)


Gary A. Ham 
Senior Research Scientist
Battelle Memorial Institute
540-288-5611 (office)
703-869-6241 (cell)
"You would be surprised what you can accomplish when you do not care who
gets the credit." - Harry S. Truman


-----Original Message-----
From: Renato Iannella [mailto:renato@nicta.com.au] 
Sent: Monday, June 20, 2005 2:06 AM
To: Emergency_Mgt_TC TC
Subject: [emergency] Info Model 2005-06-20




Dear all, attached is the draft EDXL Information Model and Semantics 
document.
It provides an Information Model (to supplement the original data model)
and uses ISO11179 model to define the semantics for each element.

I have also tried to name the elements based on their role (eg External 
Object)
rather than their data type (eg URI). I have tried to include the 
outcomes
from the recent discussions as well (eg spatial refs, list terms).

I do expect a lot more discussion on the content, and please don't 
assume
that the current model, elements, etc are in anyway final (or even 
close! ;-)


Cheers...  Renato Iannella
Project Leader, NICTA, Brisbane, QLD, AUSTRALIA
P: +61 7 3000 0484 F: +61 7 3000 0480 M: +61 4 1313 2206
E: renato@nicta.com.au W: http://nicta.com.au



------------------------------------------------------------------------
--
This email and any attachments may be confidential. They may contain
legally privileged information or copyright material. You should not
read, copy, use or disclose them without authorisation. If you are not
an intended recipient, please contact us at once by return email and
then delete both messages. We do not accept liability in connection with
computer virus, data corruption, delay, interruption, unauthorised
access or unauthorised amendment. This notice should not be removed.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]