[open-government] Ten Open Data Guidelines launched in Tbilisi

[Paola Di Maio]

Victoria,

thanks for sharing your principles. It would be nice to have some
references, and some history as to how this list was compiled,
as well as some idea of how to contribute to refine it

 Epistemologically, the first entry 'complete' may need to be qualified
further, in the sense that the notion of completeness is never fully
exhausted, unless qualified *such as complete in relation to.... (I am not
going to start ranting about Tarski)

Also I would add '*verifiable*'  and *traceable*,

Some entry on your list seem to corresponds to standard criteria for good
system specification
in which case a source reference or two would be in order

For example, see IEEE standards below

http://www.microtoolsinc.com/Howsrs.php


cheers

PDM

*
*

Again from the IEEE standard:

An SRS should be
a) Correctb) Unambiguousc) Completed) Consistente) Ranked for importance
and/or stabilityf) Verifiableg) Modifiableh) Traceable*


*

*Correct *- This is like motherhood and apple pie. Of course you want the
specification to be correct. No one writes a specification that they know is
incorrect. We like to say - "Correct and Ever Correcting." The discipline is
keeping the specification up to date when you find things that are not
correct.
**

*Unambiguous - *An SRS is unambiguous if, and only if, every requirement
stated therein has only one interpretation. Again, easier said than done.
Spending time on this area prior to releasing the SRS can be a waste of
time. But as you find ambiguities - fix them.
**

*Complete - *A simple judge of this is that is should be all that is needed
by the software designers to create the software.
**

*Consistent - *The SRS should be consistent within itself and consistent to
its reference documents. If you call an input "Start and Stop" in one place,
don't call it "Start/Stop" in another.
**

*Ranked for Importance - *Very often a new system has requirements that are
really marketing wish lists. Some may not be achievable. It is useful
provide this information in the SRS.
**

*Verifiable - *Don't put in requirements like - "It should provide the user
a fast response." Another of my favorites is - "The system should never
crash." Instead, provide a quantitative requirement like: "Every key stroke
should provide a user response within 100 milliseconds."
**

*Modifiable -* Having the same requirement in more than one place may not be
wrong - but tends to make the document not maintainable.
**

*Traceable - *Often, this is not important in a non-politicized environment.
However, in most organizations, it is sometimes useful to connect the
requirements in the SRS to a higher level document. Why do we need this
requirement?






2011/2/1 Victoria Anderica <victoria at access-info.org>

>  Dear all,
>
> Access Info Europe welcome the publication this week of the Ten Open Data
> Guidelines <http://transparency.ge/en/ten-open-data-guidelines> drafted by
> TI Georgia, in consultation with Access Info Europe.
>
> These guidelines are designed as a guide to help agency heads, IT managers,
> and web developers create open data websites. They *call* for data to be:
>
> 1. Complete
> 2. Primary
> 3. Timely
> 4. Accessible
> 5. Machine-readable
> 6. Non-proprietary
> 7. License-free
> 8. Reviewable
> 9. Discoverable
> 10. Permanent
>
> The guidelines provide details of how these are to be achieved. They
> provide a useful structure which Access Info recommends as a model for the
> elaboration of similar principles in other countries and at an international
> level.
>
> Please do not hesitate to contact either Dereck Dohler, copied, or myself
> for more information.
>
> All the best,
>
> Victoria
>  --
>
> Victoria Anderica Caffarena
> Project Coordinator
> Access Info Europe
> Madrid
> +34 91 366 53 44
> +34 606 592 976
> skype: victoria.access-info
> http://www.access-info.org/
> Síguenos en Twiter <http://twitter.com/#%21/Access_Info>, y en Facebook
> <http://www.facebook.com/pages/Access-Info-Europe/367870967220?ref=notif&notif_t=fbpage_admin#%21/pages/Access-Info-Europe/367870967220>
> Si quieres ayudar a Access Info Europe en su campaña por una ley de acceso
> a la información en España, haz click aquí<http://www.access-info.org/en/support-us>
>
> _______________________________________________
> open-government mailing list
> open-government at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/open-government
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/open-government/attachments/20110203/d38b42bb/attachment-0001.html>