- From: Jose M. Alonso <josema@w3.org>
- Date: Tue, 3 Feb 2009 21:15:34 +0100
- To: washingtona@acm.org
- Cc: John Sheridan <John.Sheridan@nationalarchives.gov.uk>, Kevin Novak <kevinnovak@aia.org>, eGov IG <public-egov-ig@w3.org>
Hi Anne, Thanks for the input. I encourage you to join the Group call on Wed. to discuss this more in detail. The audience you mention is exactly the one we are targeting. I find your suggestions interesting and much to do with me struggling on how to connect John's framework with the six topics/issues. Unfortunately I still don't get it but feel it's somewhere in here, sorry :( You mention that: > In my view, what we are left with are the types of tasks that people > will do. We have John's three modalities as a way to structure the > document. > > When creating a business process that serves the public, what are > the resources necessary to establish it, to maintain it, and to > eventually make the data accessible? I'd suggest focusing on these > questions for a management and policy audience. Could you propose an outline based on your idea or just an specific example that answers these questions? If you want editing access to add some content directly to the document just drop me a line privately. Cheers, Jose. El 01/02/2009, a las 19:47, Anne Washington escribió: > Hi All! > I wanted to provide some comments on the rough editors draft. I know > much work has gone into it since this email in December. My comments > are based on the questions below and the current contents of the > document. > > I feel the document be structured around the three part framework. > It would allow readers to identify themselves by tasks, rather than > by topic or people served. I think this document is not for > technologists but managers who are trying to understand the > challenges and resources necessary to put these ideas into production. > > Below I explain my reasoning and provide some examples. > > The G2G, G2C and C2G structure is useful but limiting. The reality > on the ground is that government is a business whose byproducts are > as valuable as the transactions. The URI handles project, for > instance, began as one thing (G2G) however it has an extended life > serving a different population (G2C). This is one reason why it is > necessary to have a lifecycle view of government information. > Because the G2 model is a dominant methodology for understanding > these issues, you might mention it but not use it for organizing the > document. > > Topic areas or technical themes are cylical and subject to change > over time. The usefulness of these documents would be severely > limited for future use if organized by topic alone. Even today, > findability is limited with out current 2009 government buzzwords. > As a librarian, I'm well aware that the way people reference ideas > is always in flux. > > The use cases exist as separate documents for additional > information. They are uniformly formatted making it easy to compare > and contrast between them. I see this document as more generic in > scope. > > In my view, what we are left with are the types of tasks that people > will do. We have John's three modalities as a way to structure the > document. > > When creating a business process that serves the public, what are > the resources necessary to establish it, to maintain it, and to > eventually make the data accessible? I'd suggest focusing on these > questions for a management and policy audience. > > Overall, looks very solid for a first draft. > > Anne Washington > > > On Wed, 17 Dec 2008, Jose M. Alonso wrote: > >> >> So, here summary notes about the call today related to this topic. >> In general, the idea looked good to those attending. >> >> John, forgot to ask you how to mach the topic areas to the >> "provide, engage, enable" framework. Just a reference from the >> topic area to the modality. Btw, what to do with G2C, G2G...? I >> don't think we need them in the Note. >> >> Once again, the pointer: >> http://www.w3.org/2007/eGov/IG/wiki/Group_Note >> >> Notes >> ----- >> 1. Outline looks good in general. >> 2. Target audience: projects managers, not developers. >> Doc should also serve those to show the policy makers >> the business case so topic areas should have references >> to the public policy goals they help to achieve. >> 3. Topic names mostly fine. Plan to have them closer to technology >> than policy is ok, but for some we should try to come up with >> something more user-friendly. >> 4. Need to prioritize them. Now already done: >> Participation, Open Government Data, Interoperability, >> Multi-channel, Auth, Long term >> (of course, we need use cases in order to develop them) >> 5. Development of every topic will have a similar structure to the >> proposed below. Need to find good names for subsections. >> 6. Need to state what we are talking about clearly, e.g. What is >> open government data in this Note context? >> 7. State business problem and use case in that context to focus on >> the problems >> >> >> I think those are the important bits. If any of the call attendants >> miss something, please speak up. >> >> I hope we could have a nearly final draft of the first two topics >> plus intro sections after the holidays. >> >> -- Josema >> >> >> El 17/12/2008, a las 14:20, Jose M. Alonso escribió: >>> Just a note for the call later. >>> I'm wondering if you have asked yourselves: what would I like to >>> see in this document that would be useful for me, that would make >>> my work easier? Please, do, in the W3C/Web context, of course. >>> Another idea. I was involved back in the days when I was managing >>> W3C Spain in a nice outreach project. Main question was: how to >>> make people aware of the W3C technologies and the way they work? >>> We developed several quick guides ([1], Spanish only, sorry) with >>> the following sections: >>> * What is it? >>> * What is for? >>> * How does it work? >>> * Examples >>> * More information >>> They were very successful and even others followed the format. >>> I'm wondering if something along these lines, per topic in the >>> Note, adapted to our needs would be useful. Rough example (not >>> well thought): >>> * What is Open Government Data? >>> * What is Open Government Data for? (or what are the benefits?) >>> * How can Open Government Data be achieved? >>> * What are the barriers and main issues to achieve it? >>> * Examples and Related Initiatives >>> Use Cases like your Website is your API, StratML, etc. >>> (it's kind of an adapted version of the use case template >>> sections, if you want) >>> I'm not how verbose every section should be though, but not much. >>> I think we should aim for a not very long document. >>> Would that be useful? Opinions? >>> -- Jose >>> [1] http://w3c.es/Divulgacion/GuiasBreves/XHTML >>> El 10/12/2008, a las 0:30, Jose M. Alonso escribió: >>>> Hi all, >>>> This message is a bit long but important, please read and comment. >>>> The very first rough editor's draft is at: >>>> http://www.w3.org/2007/eGov/IG/wiki/Group_Note >>>> Do not expect anything spectacular yet. There are many comments >>>> enclosed in "@@" for discussion and no text is final by any >>>> means. It will be evolving there based on discussions and your >>>> input is very much needed. >>>> This is mainly to discuss about the structure. I expect heavy >>>> discussion about it on the Group call and by email. >>>> The main issue for me is that of categorization. We have too many >>>> different points of view and classifications/modalities: >>>> * provide, engage, enable >>>> * G2G, G2C, C2G >>>> * Topic Areas >>>> * Use Cases >>>> * ... >>>> Oscar and I have tried to come up with a short and to the point >>>> perspective. We asked ourselves what the target audience is and >>>> what the goal of the document is (some in John's text on >>>> "provide, engage, enable") We think it's one of the main Group's >>>> goals to make W3C better speak in government terms, and that >>>> several of the topic areas identified at the F2F are too >>>> technical for that audience so we tried to Group them in areas >>>> more used by the audience and that are easier for them to >>>> recognize. Not sure if we did it well. Opinions? >>>> As an example, take "Persistent URIs". This is a technical topic. >>>> An eGov topic may be "Long term archiving" or "Long term data >>>> management", and "Persistent URIs" may be one of the means to >>>> achieve it. We thought that some topic areas where translatable >>>> 1to1 such as "Identification and Authentication". I'm still >>>> missing some eGov terminology there anyway... >>>> If this would be the way to go, we'd need one generic use case to >>>> illustrate every eGov topic area (we have 6 in there, in no >>>> particular order): >>>> * Identification and Authentication >>>> * Multi-channel delivery >>>> * Long term data management >>>> * Participation and Citizen Engagement >>>> * Transparency >>>> * Interoperability >>>> The plan would be to follow a bottom up approach: >>>> * Ongoing compilation of use cases >>>> * Take use cases that describe real projects >>>> * Group similar ones into generic ones >>>> * Exemplify every eGov area with a generic one >>>> (we'd need 6 generic ones for now) >>>> My main issue so far is that there are too many dimensions and >>>> I'm still not sure what is the best way to go. Sometimes it >>>> reminds me of the multiple dimensions of interoperability in the >>>> EIF 2.0 draft [1] (page 20). >>>> This is where we need the most input now. I hope I'm not >>>> confusing people even more and hope to give a more and better >>>> detailed explanation on the call. >>>> For every one of those final generic cases, we would use almost >>>> the same structure as that of the ones we are compiling in the >>>> wiki, may be that some fields are missing or not needed. The idea >>>> is for every of those cases to describe the eGov topic area, >>>> what's happening, what are potential ways to improve it and >>>> issues found. Probably the use case that is closest to this is so >>>> far is: >>>> http://www.w3.org/2007/eGov/IG/wiki/Use_Case_5_-_Your_Website_is_your_API >>>> With all the issues found, we'd draft the "Next Steps" (or >>>> whatever would be the name of that section) and show some >>>> potential ways to address them. It may be that we find that a >>>> standard is missing here or there and that we propose to create >>>> it. It may be that there are already best practices to address >>>> some, and we just need to point to them... etc... I think we >>>> haven't reached the maturity as a Group to develop Best Practices >>>> yet, but cold propose to do so at a later stage. It would make >>>> one nice followup to this first document. >>>> Well, that's it for now. Hope it's useful. Talk to some of you on >>>> the phone in a few hours. >>>> Cheers, >>>> Jose. >>>> [1] http://ec.europa.eu/idabc/servlets/Doc?id=31597 >>>> -- >>>> Jose M. Alonso <josema@w3.org> W3C/CTIC >>>> eGovernment Lead http://www.w3.org/2007/eGov/ >> >>
Received on Tuesday, 3 February 2009 20:16:18 UTC