Re: Improving Organization of Govt. based Linked Data Projects

[Kingsley Idehen]

Danny Ayers wrote:
On 20 March 2010 21:18, Kingsley Idehen <kide...@openlinksw.com> wrote:
  
All,

I continue to struggle with easy discovery of Government oriented Linked
Data (UK and U.S. are examples). Basically, a long time ago, we established
some core principles for Linked Open Data published to the Web. The
components where broken down as follows:

1. Publish RDF Data Set archive URLs to a well known location --
http://esw.w3.org/DataSetRDFDumps
2. Publish SPARQL Endpoints -- e.g., <http://esw.w3.org/SparqlEndpoints>
3. Publish Linked Data -- an home page or deeply linked URI will do.
    

I suspect (and hope) 1 & 2 are redundant if you have 3.
  
Yes, if #3 provides pointers to #1 & #2.
>From what I've heard from the w3c eGov list and bits of offlist chat,
it's still early days for getting government data out there. There
seems to be a lot of momentum, but right now it's directed towards
local issues, getting data into a Web-friendly form (I hate to use the
term "legacy", but a lot of the time it does seem to apply - the
source material is buried in a spreadsheet or even a pdf document).
Getting the stuff translated & exposed, linked into the rest of the
world (beyond just shared vocabs) will be phase 2 I expect.

  
DBpedia still provides a very nice template for the above.
    

Absolutely.

It's worth noting that for the gov depts to maintain credibility, that
provenance information should be associated with any data exposed - a
minor technical hassle, in most cases likely fulfilled by manual
annotation. (see the Open Provenance Model, if I understand being
RDFized in data.gov.uk http://openprovenance.org/).

  
Yes, certainly !


A related issue (that Jeni Tennison has raised) is the question of
authority over the statements. I believe she has the right idea, that
to link gov data into e.g. dbpedia, intermediary graphs are necessary,
to ring fence the levels of commitment between the national,
centralised expression of "facts" and those other facts we know and
love from the social-web world.
  
I think this applies to anything that references DBpedia but not created 
by the core project members. If you recall, there have been a number of 
DBpedia linksets (see the mailing list archives) from across the LOD 
community that we've loaded into the DBpedia instance, using distinct 
graph IRIs etc.. 
  
Unfortunately, most of the Govt oriented Linked Data projects haven't quite
adopted the scheme above thereby making the process of discovering items 1-3
quite tedious.
    

Your impatience is understandable, but from what I can gather, things
are progressing...

  
I only get demonstrably impatient when the message (easily perceived as 
a marketing message) gets out of sync with the actual deliverables.

Linked Data is about LINKs, so whenever there is talk of Linked Data 
there should be a LINK in place to materialize the value prop. of a 
given Linked Data Space. The LINK in question should really be a conduit 
to SPARQL endpoint, Data Set URLs etc., since value prop. imbibers are 
going to be varied -- naturally.

Suggestions:

I think we can tackle this problem by doing the following:

1. Use the moniker Linked Open Govt Data (LOGD) for all Govt. oriented
Linked Data projects
    

Where? A good idea in principle, but we don't really yet have the
material in place to justify a shared e.g. mailing list.

  
This is just about reference, no different to saying: LOD.

2. Use #hashtag #logd on Twitter and "logd" for tagging on del.cio.us -- one
data is on del.icio.us or Twitter, its basically part of LOD via RDFizers
etc..
    

That sounds reasonable. Anything that can help human discovery can't
hurt machine discovery.

  
That's basically my point :-)

Kingsley
So Far I have:

1. http://delicious.com/kidehen/logd  -- del.icio.us tag
    

good-o

Cheers,
Danny.


  


--

Regards,

Kingsley Idehen	      
President & CEO 
OpenLink Software     
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen