W3C home > Mailing lists > Public > public-egov-ig@w3.org > May 2009

RE: charter and publication wrt W3C Process

From: Owen Ambur <Owen.Ambur@verizon.net>
Date: Wed, 20 May 2009 10:10:25 -0400
To: "'eGov IG'" <public-egov-ig@w3.org>
Message-id: <000001c9d954$b8dd7050$2a9850f0$@Ambur@verizon.net>
While I wouldn't exactly call it a "small" document, I agree that the Web
Accessibility Initiative's (WAI) Accessible Rich Internet Applications
(ARIA) best practices are a good example of the kind of deliverable the eGov
IG could produce that might actually be useful to stakeholders who are
capable of using it.
http://www.w3.org/TR/wai-aria-practices/#accessiblewidget 

I also agree that a good topic of focus for the eGov IG would be open
government data (OGD), such as:  

a) how agencies can make their data more readily discoverable and usable,
and

b) in turn, how stakeholders (including intermediary service providers) can
measure and assess the degrees to which agencies have done so (recognizing
that perfection is not the goal and progress generally occurs in many small
steps).

In the U.S. federal government, the Federal Enterprise Architecture (FEA)
Data Reference Model (DRM) was supposed to serve that function.
http://en.wikipedia.org/wiki/Federal_Enterprise_Architecture#Data_Reference_
Model_.28DRM.29  However, since agency DRM's themselves are not readily
discoverable and usable, the FEA DRM as currently being "practiced" cannot
possibly serve the function for which it was intended, at least not for
external stakeholders (e.g., citizens).

The draft XSD for the DRM, which would have made the DRM data itself "open"
but was not finalized and implemented, is available at
http://xml.gov/draft/drm20060105.xsd 

Other ways of viewing this potential initiative for the eGov IG are as:

1) an internationalized set of best practices for implementing President
Obama's directive on transparency and open government, which is available in
StratML format at http://xml.gov/stratml/DTOG.xml, and 

2) providing practical proposals for prospective implementation in services
like http://data.gov/ 

Of course, too, I believe it would be good to explicitly identify our
stakeholders -- both performers (who are volunteering to do the work) as
well as prospective beneficiaries, whom we should try to engage in providing
feedback as well as eventually *using* our deliverable(s).  Ideally, we
would identify our stakeholders (together with our goals and objectives) in
a readily shareable format like StratML and, thus, practice what we preach
while demonstrating leadership by example.

Owen

-----Original Message-----
From: public-egov-ig-request@w3.org [mailto:public-egov-ig-request@w3.org]
On Behalf Of Jose M. Alonso
Sent: Wednesday, May 20, 2009 7:50 AM
To: Sharron Rush
Cc: eGov IG
Subject: Re: charter and publication wrt W3C Process

> ...
>>  + a set of small docs with guidance?
>>   (could be recs or not)
>
> I am not sure what these "small docs" would do that would not be  
> included in BP and the rewritten Note, but am open to suggestion.  
> Are you thinking of technical documents that would be more of a how- 
> to?  a series of case studies of particularly effective practices?

I was thinking of small how-to like things, e.g. techniques to  
identify and expose OGD, but also identification of scenarios to do  
so. More how-to than case studies.

>  The suite of ARIA documents could be a model, I suppose.

Maybe... I like this how-to piece:
http://www.w3.org/TR/wai-aria-practices/#accessiblewidget

>  This one requires more consideration and could be decided after  
> being chartered, is that not so?  or do we need to state our entire  
> scope of work at the time of charter?

As specific as possible is always welcome, but we can definitely leave  
some room as we did first time. More on charters:
http://www.w3.org/2005/10/Process-20051014/groups#WGCharter


>>  + a second version of the Note?
>>   (no need to be a rec, as you know)
>
> Yes, the Note must be rewritten for coherence, narrative flow,  
> conclusions, etc.

Heard several saying this. I don't have an opinion yet besides that  
this should be done if there are group members willing to take on this  
task.


>> In summary: going normative is "stronger" but has more implications:
>> patent policy matters, strongest coordination with other groups, more
>> process-related stuff to deal with...
>
> If we are saying that we will produce normative standards and expect  
> eGov practitioners around the world to begin to claim "conformance"  
> to these standards,  that is a mighty undertaking.  Think of the  
> arduous processes around WCAG2 and HTML5.  Also, eGov is a bit less  
> easily defined because of cultural influences, history, forms of  
> government etc.  I would advise that we not commit to normative  
> output at this time, but as previously stated, happy to hear another  
> point of view.

Ok, thanks. I think I'm more of a non-normative opinion so far.


> Please let me know if this is the type of input needed and/or if I  
> have overlooked any questions.

Very much so, thanks!
If you have something more specific in mind about the content we  
should produce, please share it, too.

Cheers,
Jose.


> Thanks,
> Sharron
>
>> [1] http://www.w3.org/Consortium/Process/
>> [2] http://www.w3.org/2005/10/Process-20051014/groups#GAGeneral
>> [3] http://www.w3.org/2008/02/eGov/ig-charter
>> [4] http://www.w3.org/2004/02/05-patentsummary
>> [5] http://www.w3.org/2005/02/AboutW3CSlides/images/groupProcess.png
>> [6] http://www.w3.org/2005/10/Process-20051014/tr#Reports
>> [7] http://www.w3.org/Guide/Charter
>> [8] http://www.w3.org/TR/mobile-bp/
>>
>> --
>> Jose M. Alonso <josema@w3.org>    W3C/CTIC
>> eGovernment Lead                  http://www.w3.org/2007/eGov/
Received on Wednesday, 20 May 2009 14:11:12 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 20 May 2009 14:11:12 GMT