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

 


Help: OASIS Mailing Lists Help | MarkMail Help

egov message

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


Subject: Re: [egov] Proposed Infrastructure SC


All,

There may be some potential synergies here between these ideas and the
Federal CIO Council XML Registry Working Group. Additionally, Booz Allen
has created a business case for an XML.gov Registry which is available
on the XML.gov Web site [1].

Kind Regards,
Joe Chiusano
Booz | Allen | Hamilton

[1] http://xml.gov/documents/completed/bah/registryBusinessCase.htm

Duane Nickull wrote:
> 
> Just to clarify - I am a *huge* fan of not re-inventing stuff.  In no
> way should we devise YARS (Yet another Registry Scheme).  OASIS already
> has one more than they probably need (no flames please on which one is
> better ;-)
> 
> The intent of my post was to convey my own experiences that a Best
> practices/implementation guide of existing registries would help eGov.
>  Same with Architecture.  If we do an architecture, it should possibly
> be on adapting an existing architecture such as ebXML or WSA to eGov.
> 
> What would also be nice is a requirements document. Perhaps some of the
> Gov folks can steer the next actions for this group based on what is
> needed.  I am also a huge fan of technology being driven by real world
> needs.  The last thing we all need to do is to develop new technology
> that will sit on a shelf becuase no one actually needs it.
> 
> Duane Nickull
> 
> Matthew Dovey wrote:
> 
> >There is a wealth of activity on metadata registries ranging from ISO 11179 Schema registries to technotes on how to use UDDI and ebXML in this context. I may be misinterpreting the remit of this SC and this TC (having only recently joined as an observer) but I would have thought that an overview of these technologies plus perhaps best practice/recommendations on implementing these technologies would be useful. However, the SC should not invent yet another new technology/approach where ones already exist (but I don't think that is the intent).
> >
> >Matthew Dovey
> >Oxford University
> >_____________Original message ____________
> >Subject:       Re: [egov] Proposed Infrastructure SC
> >Sender:        Robert Greeves <GREEVESR@OJP.USDOJ.GOV>
> >Date:          Fri,  4 Apr 2003 03:49:10 +0100
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> > These are issues that are very important to what we are currently
> > pursuing in the Office of Justice Programs, U.S. Dept. of Justice.
> > However, my concern is whether they (a) belong in the Infrastructure
> > Working Group and/or (b) whether they even belong in this TC? Aren't
> > there other TC's focusing on this type of capability?
> >
> > ***************************************************************************
> >
> > >>> Duane Nickull <duane@yellowdragonsoft.com> 04/02/03 01:02PM >>>
> > I would propose one deliverable be an implementation/best practices
> > guide for Governments to implement a metadata Registry for publishing
> > and subsequent discovery of key metadata.  My past experience with
> > government registries has been very enlightening and I can see a clear
> > value in delivering such a proposal.  I woudl also argue that this may
> > be a good first deliverable due to the amount of current interest in
> > establishing a Registry centric concept of operations for many
> > governments.
> >
> > I can flesh this idea out further if there is interest.  Can we solicit
> > comments from the governments participating on this list?  Please give
> > this idea a sanity check ;-)
> >
> > If it goes ahead,  I would volunteer to get this started.
> >
> > The other candidate may be an architecture for using Registries within
> > eGovernment to help guide implementations.  As opposed to a technical
> > architecture,  this could be a reference architecture.
> >
> > Duane Nickull
> >
> > Eliot Christian wrote:
> >
> > > The following statement of Scope and Purpose for the proposed
> > > Infrastructure Subcommittee incorporates suggestions of several
> > > participants in the OASIS E-Government Technical Committee:
> > > Owen Ambur, John Borras, Diane Lewis, Jim Rice, and Sinisa Zimek.
> > > I hope that I have captured the intent of the suggestions, while
> > > exercising some editorial license to maintain readability. Please
> > > do let me know if you object to adoption of this statement.
> > >
> > > -----------------------------------------------------------------
> > >
> > > Scope and Purpose: Within the scope of the E-Government Technical
> > > Committee, the Infrastructure Subcommittee focuses on common
> > > facilities applied in multiple government functions. Examples
> > > of common facilities include Security and Authentication,
> > > Privacy Assurance, Geospatial Facilities, Metadata Facilities,
> > > E-forms Facilities, Identity Services, Interface Management,
> > > Information Discovery, Records Management, Taxonomy Management,
> > > Registry and Repository Facilities, and Organization Directories,
> > > among others. Common facilities addressed by the Infrastructure
> > > Subcommittee are component technology solutions used by the
> > > various government functions delineated by the Services
> > > Subcommittee and the various E-Government projects highlighted
> > > by the Best Practices Subcommittee. Common facilities addressed
> > > by the Infrastructure Subcommittee also make use of the technical
> > > mechanisms addressed by the Interoperable Services Subcommittee,
> > > which are independent of particular government functions or
> > > common facilities.
> > >
> > > -----------------------------------------------------------------
> > >
> > > Assuming that we are now close to consensus on the Scope
> > > and Purpose statement of the Infrastructure Subcommittee,
> > > please circulate any suggestions on specific Deliverables.
> > > Each Deliverable should be described with a short paragraph
> > > accompanied by an estimate of the expected level of effort
> > > and time to completion.
> >
> >
> > --
> > ***************************************************
> > Yellow Dragon Software - http://www.yellowdragonsoft.com
> > Professional Software Development & Metadata Management
> > Project Team Lead - UN/CEFACT eBusiness Architecture
> >
> >
> >
> >
> >
> 
> --
> ***************************************************
> Yellow Dragon Software - http://www.yellowdragonsoft.com
> Professional Software Development & Metadata Management
> Project Team Lead - UN/CEFACT eBusiness Architecture
begin:vcard 
n:Chiusano;Joseph
tel;work:(703) 902-6923
x-mozilla-html:FALSE
url:www.bah.com
org:Booz | Allen | Hamilton;IT Digital Strategies Team
adr:;;8283 Greensboro Drive;McLean;VA;22012;
version:2.1
email;internet:chiusano_joseph@bah.com
title:Senior Consultant
fn:Joseph M. Chiusano
end:vcard


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