MHonArc v2.5.0b2 -->
emergency message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [emergency] GJXDM vs EDXL Distribution isses
I have received some very good comments on GJXDM from some OGC members. They
have asked me to bundle the comments up and pass them on. I was wondering
what the best mechanism would be to properly share these comments with the
GJXDM folks?
Thanks for any guidance.
Carl
----- Original Message -----
From: "Daconta, Michael" <Michael.Daconta@dhs.gov>
To: <rexb@starbourne.com>; <acb@incident.com>; "Daconta, Michael"
<Michael.Daconta@dhs.gov>; <emergency@lists.oasis-open.org>
Sent: Thursday, December 30, 2004 6:02 AM
Subject: Re: [emergency] GJXDM vs EDXL Distribution isses
> Hi Everyone,
> I will email the group later with more thoughts on GJXDM. In general, I
> agree with Rex's position below. My concern I expressed yesterday was
> because I have seen it many times before where groups favor invention over
> reuse. I know the GJXDM is not perfect but I also believe it is well
> worth the effort to fix, improve and reuse it.
> --------------------------
> Sent from my BlackBerry Wireless Handheld
>
>
> -----Original Message-----
> From: Rex Brooks <rexb@starbourne.com>
> To: Art Botterell <acb@incident.com>; Daconta, Michael
> <Michael.Daconta@dhs.gov>; emergency@lists.oasis-open.org
> <emergency@lists.oasis-open.org>
> Sent: Wed Dec 29 18:53:42 2004
> Subject: Re: [emergency] GJXDM vs EDXL Distribution isses
>
> Just to add my $.02 a bit further, I don't think there is much chance
> of us adopting a "not-invented-here" parochialism. Since a few of us
> are trudging through the entire GJXDM to discover what and where the
> differences are with the work we've done so far, I suspect that we
> will most likely recommend best practices for implementors to use the
> appropriate namespaced term. To do that we must first do the
> diligence of comprehensive comparison so we can then look at
> similarities, duplications and differences and make our
> recommendations.
>
> And just to add a bit more, while I am keeping my mind open to
> alternatives, I suspect we will end up settling on the use of an
> ontological approach to making our recommendations: for uses in
> inontology/taxonomy x, use schema a, for uses in ontology/taxonomy y,
> use b, etc. I am personally in favor of using existing work whereever
> it doesn't require too many extensions to cover the requirements we
> have scoped for the particular piece of work.
>
> Ciao,
> Rex..
>
> At 1:14 PM -0800 12/29/04, Art Botterell wrote:
>>Michael, it's not my intent to disturb you. However, I assume you'd
>>agree that there's also a risk in trying to force what may prove to
>>be unlike concepts into like boxes just for short-term convenience.
>>
>>We need to look carefully at the realities of the real-world
>>applications and processes before reflexively adopting prior art
>>just because "it was there first." I'm sure you're not suggesting
>>the latter approach. Nor have I ever objected to reuse where it's
>>appropriate.
>>
>>- Art
>>
>>
>>At 4:04 PM -0500 12/29/04, Daconta, Michael wrote:
>>>This email thread is disturbing... I would hope this TC can avoid
>>>the "not invented here syndrome" and focus on reusing schema
>>>elements where the concepts are equivalent or can be aligned.
>>>--------------------------
>>>Sent from my BlackBerry Wireless Handheld
>>>
>>>
>>>-----Original Message-----
>>>From: Art Botterell <acb@incident.com>
>>>To: emergency@lists.oasis-open.org <emergency@lists.oasis-open.org>
>>>Sent: Wed Dec 29 15:43:52 2004
>>>Subject: Re: [emergency] GJXDM vs EDXL Distribution isses
>>>
>>>At 9:34 AM -0500 12/29/04, Ham, Gary A wrote:
>>>>To be GJXDM compliant we would probably have to change the "eventType"
>>>>to something more akin to "EmergencyEventTypeCode"...
>>>
>>>I'm not sure whether "compliant" is the right criterion. Our
>>>functional goal is "compatible"... framing it in terms of compliance
>>>transforms a technical issue into a political one. I'm not sure
>>>that's either necessary or wise.
>>>
>>>Not necessary because we have the mechanism of namespaces to allow
>>>domain-specific element design choices to be made "close to the
>>>ground," nearer to functional concerns and farther from bureaucratic
>>>ones. It gives us a viable alternative to the
>>>grand-unified-data-model-of-everything approach, which I'm afraid may
>>>be self-defeating in its scope.
>>>
>>>And not wise for several reasons:
>>>
>>>1) Adopting a stance of "compliance" to one user group... in this
>>>case, the justice community... necessarily distances us a bit from
>>>others... fire, transportation, health, etc. While I realize that
>>>Justice is ascendant in post-9/11 America, we're part of an
>>>international standards organization and those of us who've been at
>>>this for awhile have seen these trends shift back and forth over the
>>>decades.
>>>
>>>2) There's a learning curve here. As Gary points out, just because
>>>the GJXDM was the earliest and largest doesn't mean it got everything
>>>right. We need to leave the door open for learning and improvement.
>>>(After all, the US had the first color television standard in the
>>>world... and as a result spent the next forty years looking at the
>>>worst color tv pictures in the world.)
>>>
>>>3) As mentioned above, the wider the scope of a data model, the more
>>>technical and political inertia it accumulates. Keeping a degree of
>>>compartmentalization lends flexibility, so long as there's a
>>>mechanism (e.g., namespaces) for preventing collisions.
>>>
>>>Now I'm not arguing against adopting an ISO 11179-based naming
>>>scheme. I'm just suggesting that we ought to think carefully and
>>>explicitly before slipping into an assumption that we're somehow
>>>obliged to comply with some other group's scheme.
>>>
>>>- Art
>>>--
>>>Art Botterell
>>>Common Alerting Protocol Program Manager
>>>Partnership for Public Warning
>>>www.PartnershipForPublicWarning.org
>>>(707) 750-1006
>>>
>>>To unsubscribe from this mailing list (and be removed from the
>>>roster of the OASIS TC), go to
>>>http://www.oasis-open.org/apps/org/workgroup/emergency/members/leave_workgroup.php.
>>
>>
>>To unsubscribe from this mailing list (and be removed from the
>>roster of the OASIS TC), go to
>>http://www.oasis-open.org/apps/org/workgroup/emergency/members/leave_workgroup.php.
>
>
> --
> Rex Brooks
> President, CEO
> Starbourne Communications Design
> GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth
> W3Address: http://www.starbourne.com
> Email: rexb@starbourne.com
> Tel: 510-849-2309
>
>
> To unsubscribe from this mailing list (and be removed from the roster of
> the OASIS TC), go to
> http://www.oasis-open.org/apps/org/workgroup/emergency/members/leave_workgroup.php.
>
>
>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]