All posts in the topic FYI: SSC blog on exposing non-personal data (Short link)
Summary
- There are 9 posts — by 5 authors — in this topic.
- Latest post made by Robert Coup at Aug 05 12:12 NZST
http://blog.e.govt.nz/index.php/2009/08/03/exposing-non-personal-data-in-new-ways/ It includes a list of links to a number of government dataset, database and other information resources.
On Tue, Aug 4, 2009 at 5:38 PM, Mike Pearson <email obscured>>wrote: > > http://blog.e.govt.nz/index.php/2009/08/03/exposing-non-personal-data-in-new-ways/ Yes, congrats to Keitha for this, and for the followup article in ComputerWorld mentioning Keitha's post, and the open.org.nz initiative. http://computerworld.co.nz/news.nsf/news/FB2128387FC35C61CC25760800193D33
On Wed, Aug 5, 2009 at 10:54 AM, Julian Carver <email obscured> > wrote: > On Tue, Aug 4, 2009 at 5:38 PM, Mike Pearson <email obscured> > >wrote: > > > > > > http://blog.e.govt.nz/index.php/2009/08/03/exposing-non-personal-data-in-new-ways/ > > > Yes, congrats to Keitha for this, and for the followup article in > ComputerWorld mentioning Keitha's post, and the open.org.nz initiative. > http://computerworld.co.nz/news.nsf/news/FB2128387FC35C61CC25760800193D33 > My only question was... why go to the effort of doing Excel and CSV and Atom and not add an HTML version? I mean, we all love machine readable but HTML is a great way to check out relevance (for a potential consumer) as well as get found in search results... Rob :)
> My only question was... why go to the effort of doing Excel and CSV
> and Atom and not add an HTML version?
>
So we need an agreed set of standard formats for dataset METARECORDS ?
It would be useful to have an agreed set of standard formats for datasets
AND for dataset metarecords.
The trick would be to apply the 80/20 rule, as adding extra "standard
formats" later, will increase costs.
Suggestions
Datasets: CSV/TXT, XML, KML/KMZ
Metarecords: HTML, CSV, ATOM
Note that the purpose of ATOM is presumably to notify subscribers of
changes/updates.
um - I might be missing the point here, but I clicked the ATOM link in my
browser and got a perfectly good HTML representation to read.
Andrew
2009/8/5 Mike Pearson <email obscured>>
On 4/08/2009, at 5:03 PM, Robert Coup wrote:
> My only question was... why go to the effort of doing Excel and CSV
> and Atom and not add an HTML version?
> I mean, we all love machine readable but HTML is a great way to
> check out
> relevance (for a potential consumer) as well as get found in search
> results...
I don't think the point of this was to get into Google -- it's not a
data.govt.nz kind of effort, this is just fact-finding and "proof-of-
concept" (the concept being "it's possible to build a list of
government data sources"). Now SSC want us to tell them how well this
works for us:
On Wed, Aug 5, 2009 at 11:31 AM, Andrew Watkins <email obscured>> wrote:
> um - I might be missing the point here, but I clicked the ATOM link in my
> browser and got a perfectly good HTML representation to read.
Sure thing, I did that too. Misses out the contact details, dataset urls,
and rights information. I then viewed source, copied and pasted into a text
editor, ran xml-tidy, and scrolled through ;)
I think the accessibility to non-geek user (eg. NBR or Computerworld reader)
who might want some data is approaching zero though.
Rob :)
On 3/08/2009, at 11:38 PM, Mike Pearson wrote: > http://blog.e.govt.nz/index.php/2009/08/03/exposing-non-personal-data-in-new-ways/ > > It includes a list of links to a number of government dataset, > database and > other information resources. It raises interesting questions--included in the responses are: - software (e.g., the metadata extractor from National Library) - blogs (e.g., NZ Poet Laureate blog) - umbrella websites (e.g., Statisphere) - disclaimers in the licensing terms (e.g., School enrolment zones) - PDF files (e.g., Gambling Statistics) I just posted a response to the blog post talking about data quality, crowdsourcing, and bulk-downloads vs browsing/searching.
Hi Mike,
On Wed, Aug 5, 2009 at 11:13 AM, Mike Pearson <email obscured>>wrote:
>
> So we need an agreed set of standard formats for dataset METARECORDS ?
>
> It would be useful to have an agreed set of standard formats for datasets
> AND for dataset metarecords.
>
> The trick would be to apply the 80/20 rule, as adding extra "standard
> formats" later, will increase costs.
Yeah, I guess this forms part of the how-to-open guide :)
> Suggestions
>
> Datasets: CSV/TXT, XML, KML/KMZ
>
> Metarecords: HTML, CSV, ATOM
>
> Note that the purpose of ATOM is presumably to notify subscribers of
> changes/updates.
Atom & friends (AtomPub, etc) can be a great format for disseminating
information as XML, not just "news" or temporal data. It is really
extensible - there are "modules" for times, locations, media, geography, and
it's easy to incorporate domain-specific xml as well. It has a good base of
"standard" stuff which means things like Firefox/Safari/Google
Reader/TwitterFeed can consume a basic version with no effort.
Turning any XML into a semi-useful HTML page can be done through XSLT
automatically, or the same thing is easily templated if there's a dynamic
web site.
Microformats make HTML pages machine-parseable easily... this can be as
simple as using class="something" attributes on the tags containing
different types of content. There are standards (hCard, hCalendar, XFN) for
dates, events, locations, relationships, etc.
So, my personal view in order of preference:
Metarecords: HTML (preferably with Microformats), Atom
Datasets: XML (preferably built off Atom/AtomPub), CSV, KML (spatial only)
What do others think?
Rob :)