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] HAVE draft comment posted


Thanks Carl,

It is helpful to know this. The OGC issues are the same kind if not 
the same domain of question that we need to answer.

Cheers,
Rex

At 10:06 AM -0700 11/2/06, Carl Reed OGC Account wrote:
>Just to weigh in on this dialogue and using the OGC to provide some 
>perspective.
>
>The OGC has invested considerable time and effort in defining, 
>documenting, and approving a variety of documents related to naming, 
>vocabularies, metadata, and registries and so forth. This includes 
>close collaboration with ISO TC-211 and the IETF. Obviously, this 
>work is from a geospatial perspective. However, the following might 
>be of interest in terms of providing additional input into this 
>dialogue.
>
>The OGC has a set of documents called the Abstract Specification. 
>These documents describe the information and reference models for a 
>variety of topics for geospatial content and services. These topics 
>include geospatial information domains such as metadata, features, 
>registries, spatial referencing by coordinates, and most recently 
>geo-digital rights managements. If we look more closely at metadata, 
>the OGC and ISO have agreed that ISO 19115 is the international 
>standard for expressing geo-metadata. In that document, there is 
>considerable reference to ISO 11179.
>
>For example:
>The entities and elements within the data dictionary are defined by 
>seven attributes (those attributes are listed below and are based on 
>those specified in ISO/IEC 11179-3 for the description of data 
>element concepts, i.e. data elements without representation). The 
>term "dataset" when used as part of a definition is synonymous with 
>all types of geographic data resources (aggregations of datasets, 
>individual geographic features and the various classes that compose 
>a feature).
>
>This approach is independent of the actual NDR used. The OGC 
>approach to registries is also grounded in the work of ISO.
>
>The reason for this input is a follow-on to Sukumar's concern. As is 
>Sukumar, I am not opposed to the NIEM NDR. However, there does need 
>to be due diligence. Further, one issue I have is the NIEM may be 
>perceived as US centric. OASIS is an international organization that 
>is working on international standards. Finally, while I may be off 
>base here (and Sukumar please correct me if I am), but to do this 
>type of analysis we need an information model.
>
>Sorry about the length, but this topic is very similar to discussion 
>we are having in the OGC about the OGC NID, naming authorities, 
>registries, and governance of these things.
>
>Cheers
>
>Carl
>
>
>----- Original Message ----- From: "Sukumar Dwarkanath" 
><sdwarkanath@comcare.org>
>To: "Tim Grapes" <tgrapes@evotecinc.com>; "Lee Tincher" 
><ltincher@evotecinc.com>; "Rex Brooks" <rexb@starbourne.com>; "Elysa 
>Jones" <ejones@warningsystems.com>; <emergency@lists.oasis-open.org>
>Sent: Thursday, November 02, 2006 8:06 AM
>Subject: RE: [emergency] HAVE draft comment posted
>
>>All,
>>
>>I am not against the NIEM NDR, but the TC should conduct the due
>>diligence to understand if there are other alternatives or
>>recommendations from OASIS. I do not want to be stuck in a position
>>where we adopt this now, and OASIS then stipulates another NDR...
>>
>>This will be a substantive change as it not just a change in the
>>semantics but it involves a lot more effort - you need to align to the
>>schema design rules, data modeling rules etc. Which brings me to my next
>>question - what stage is this document in? The reason I ask is that I do
>>not see any content in Sec 11, 12 etc.
>>
>>I agree with the notion that we need to adopt a NDR and apply it
>>consistently for all products, but we need to make sure that what we
>>conduct the due diligence.
>>
>>Sukumar
>>
>>
>>
>>-----Original Message-----
>>From: Tim Grapes [mailto:tgrapes@evotecinc.com]
>>Sent: Thursday, November 02, 2006 9:16 AM
>>To: 'Lee Tincher'; 'Rex Brooks'; 'Elysa Jones';
>>emergency@lists.oasis-open.org
>>Subject: RE: [emergency] HAVE draft comment posted
>>
>>Hey Rex,
>>
>>I do understand where you are coming from, but my feeling is that now is
>>the
>>time to adopt the NDR, before we have a release.  The NDR is conformant
>>to
>>ISO 11179, and I don't think it would be considered a substantive change
>>-
>>the structure and definitions are the same.  We would only be changing
>>the
>>semantics.  It should not break existing applications since HAVE is only
>>a
>>draft, and should only be used to this point for pilots and demos.
>>
>>I do believe the time is now to incorporate this, but perhaps I don't
>>fully
>>understand the argument you put forth. As it stands, the TC has
>>incorporated
>>naming logic not based upon an NDR.  We're simply recommending adoption
>>of a
>>specific convention that will cure a lot of headaches down the pike.
>>
>>Thanks,
>>
>>Tim
>>
>>
>>-----Original Message-----
>>From: Lee Tincher [mailto:ltincher@evotecinc.com]
>>Sent: Thursday, November 02, 2006 9:02 AM
>>To: 'Rex Brooks'; 'Tim Grapes'; 'Elysa Jones';
>>emergency@lists.oasis-open.org
>>Subject: RE: [emergency] HAVE draft comment posted
>>
>>Rex,
>>
>>If we waited until the next version to adopt the NDR wouldn't that put
>>us in
>>the position of having an immediate major release (v2.0) since I doubt
>>that
>>it would be backwards compatible from the initial release?
>>
>>Thanks,
>>Lee
>>'We the unwilling, led by the unknowing have been doing the difficult
>>with
>>little for so long that we are now ready to tackle the impossible with
>>nothing.' -- Local Fire communications reserve volunteer motto
>>
>>-----Original Message-----
>>From: Rex Brooks [mailto:rexb@starbourne.com]
>>Sent: Thursday, November 02, 2006 8:56 AM
>>To: Tim Grapes; 'Elysa Jones'; emergency@lists.oasis-open.org
>>Subject: Re: [emergency] HAVE draft comment posted
>>
>>Hi Tim,
>>
>>I posed my initial response earlier, but I wanted
>>to specifically address where in the process this
>>should be taken up wrt HAVE.
>>
>>My own feeling (subjective) is that it should be
>>held back until a subsequent version, e.g. v1.1.
>>or 2.0 because I suspect it will meet the
>>criterion that a substantive change requiring a
>>new 60-day public review has a threshold or
>>trigger whereby a substantive change is one that
>>"breaks" existing applications.
>>
>>Objectively, we literally can't afford to hold
>>this up, or vendors will produce their own
>>menagerie of proprietary solutions. This is what
>>happened for the OASIS SOA Reference Model TC
>>(and current Reference Architecture SC). It has
>>endured and continues to face the proliferation
>>of ESBs and "SOA Fabrics"  jockeying for the
>>inside track in the marketplace while we
>>carefully crafted the Reference Model and
>>continue to work on the Reference Architecture.
>>However, because both the model and architecture
>>are largely abstract, much like we can make the
>>NDR we can, I believe, absorb ESBs and Fabrics,
>>albeit with a very flexible shoe horn.
>>
>>So while the comparison is not precise, the
>>effect that ESB vendors have been running away
>>with the marketplace still applies.
>>
>>So we will have to attempt to incorporate NDR,
>>crafting it as a non-breaking, non normative
>>"best practice" in an appendix during and
>>immediately after the 60-day review IF we have
>>the time--which is to say, IF we are not swamped
>>with industry comments. We will also need to
>>include the advice that we expect to incorporate
>>a general-purpose NDR methodology in the next
>>version of HAVE and EDXL_DE along with all
>>subsequent members of the EDXL family.
>>
>>We may be able to do this because what we are
>>doing is establishing a methodology for NDR, not
>>a controlled vocabulary in itself. If NIEM is
>>looking for a the greater restriction of its own
>>controlled vocabulary, which is what we feared
>>early on in Mike Daconta's initial statements, we
>>would have a greater challenge, and I would have
>>to take the position that we are required to
>>ensure international applicability over any
>>specific national systems.
>>
>>Either way, its a tough pill that it is better to
>>take now than postpone because it is not going to
>>taste any better, and likely to ferment into much
>>worse, if we wait.
>>
>>Cheers,
>>Rex
>>
>>At 2:57 PM -0500 11/1/06, Tim Grapes wrote:
>>>All,
>>>
>>>I and others on and off the OASIS EM-TC would
>>>like to post a recommendation that the National
>>>Information Exchange Model (NIEM) Naming and
>>>Design Rules (NDR) be adopted and applied to the
>>>HAVE committee draft.  My understanding is that,
>>>although a consistent convention was used to
>>>name the elements, no formal NDR has been
>>>followed for HAVE or for Resource Messaging (RM).
>>>
>>>Please note that not adopting the NDR does not
>>>prevent use of NIEM to develop exchanges using
>>>EDXL standards; however, the difficulty for
>>>practitioners may be increased otherwise.  I
>>>realize that this feels Federal
>>>government-driven, but I don't see a down-side
>>>since the particular semantics applied should
>>>not negatively impact the International
>>>community.
>>>
>>>Benefits:
>>>.         Use HAVE as the starting point to
>>>begin applying a published and consistent naming
>>>convention across the EDXL standards
>>>.         Promote reuse and facilitate simpler
>>>and more seamless use of NIEM for the
>>>development of IEPD's and implementation of
>>>exchanges using the EDXL standards.
>>>.         Provide a straight-forward avenue and
>>>mechanism for state and local organizations to
>>>comply with grants language which specifies NIEM
>>>and EDXL
>>>
>>>We do not feel that the specification should be
>>>held up; HAVE should proceed into the 60-day
>>>comment period with this and other comments that
>>>have been posted.  If adopted by the TC,
>>>recommend that the NIEM NDR be adopted for the
>>>draft Resource Messaging and subsequent
>>>standards, and possibly to the Distribution
>>>Element when a successive version is put forth.
>>>
>>>I welcome any comments or feedback.  I will be
>>>on the call Thursday at 4:45.  Because HAVE is
>>>pending committee vote, I don't know where this
>>>comment should be formally posted.  Please
>>>advise and I will ensure that gets done.
>>>
>>>Sincerely,
>>>Tim Grapes
>>>Evolution Technologies, Inc.
>>>Office:  (703) 654-6075
>>>Mobile:  (703) 304-4829
>>><mailto:tgrapes@evotecinc.com>tgrapes@evotecinc.com
>>>
>>>
>>>From: Elysa Jones [mailto:ejones@warningsystems.com]
>>>Sent: Wednesday, November 01, 2006 6:18 AM
>>>To: emergency@lists.oasis-open.org
>>>Subject: [emergency] Call for quorum - Thurs 11/2 4:45PM EST
>>>
>>>Dear EM-TC Members,
>>>
>>>We did not have a quorum for our meeting
>>>yesterday and we would like to get the HAVE
>>>moved forward to public comment, as well as
>>>review/approve the meeting notes for the past
>>>few meetings.  We had our meeting which is
>>>summarized in the notes that will be uploaded
>>>for review but without a quorum, we were not
>>>able to do any business.  We will plan to have a
>>>short meeting on Thursday just before the
>>>Msg/Not meeting on Resource Thursday evening at
>>>4:45PM EST.  The EM-TC part of the meeting
>>>should only last 15 minutes if everyone can be
>>>prepared to vote on HAVE.  If you have any
>>>issues on the draft as it is posted or
>>>corrections to the meeting notes for the Sept
>>>and Oct meetings, please post them to the list
>>>as soon as possible.
>>>
>>>Thanks!
>>>Elysa Jones, Chair
>>>OASIS EM-TC
>>>Engineering Program Manager
>>>Warning Systems, Inc.
>>>
>>>PS - The EIC meeting will be today Nov 1.  You
>>>can dial in to 800-320-4330 pin # 327547
>>>
>>>--
>>>No virus found in this incoming message.
>>>Checked by AVG Free Edition.
>>>Version: 7.1.409 / Virus Database: 268.13.20/508 - Release Date:
>>10/31/2006
>>>
>>>
>>>--
>>>No virus found in this outgoing message.
>>>Checked by AVG Free Edition.
>>>Version: 7.1.409 / Virus Database: 268.13.22/512 - Release Date:
>>11/1/2006
>>>
>>>
>>>Attachment converted: Macintosh HD:NIEM_NDR-0.3.pdf (PDF /<IC>)
>>(0019F2A1)
>>
>>
>>--
>>Rex Brooks
>>President, CEO
>>Starbourne Communications Design
>>GeoAddress: 1361-A Addison
>>Berkeley, CA 94702
>>Tel: 510-849-2309
>>
>>--
>>No virus found in this incoming message.
>>Checked by AVG Free Edition.
>>Version: 7.1.409 / Virus Database: 268.13.22/512 - Release Date:
>>11/1/2006
>>
>>
>>--
>>No virus found in this outgoing message.
>>Checked by AVG Free Edition.
>>Version: 7.1.409 / Virus Database: 268.13.22/512 - Release Date:
>>11/1/2006


-- 
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-849-2309


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