[open-data-manual] Linked Data - its place in the Open Data Manual

[Tim McNamara]

On 4 August 2011 11:50, Jeen Broekstra <jeen.broekstra at gmail.com> wrote:
> On 04/08/11 11:02, Tim McNamara wrote:
>> Linked Data - should it be in the manual? (yes)
>> What level of detail? (introduction + glossary)
>
> The main principles (the 4 steps) can be used as the base structure, using a
> couple of paragraphs for each step to elaborate.
>
> I would perhaps go just a little bit into the technical side of things,
> glossing over the real implementation details, but just to show what the
> general idea is: a couple of simple examples of what, for example, an Excel
> spreadsheet would look like when 'translated' to linked data (RDF), and how
> a linked data API makes very powerful search/query over the data (via
> SPARQL) possible.

Fair comments. Graphs are great. Examples are great. Examples of
graphs are therefore probably great^2.


> I guess that it should somehow tie in with the section on how to make data
> available (online methods) - right next to the "as an API" section?
>
>> How will it get written? (Undecided, perhaps Italians write their own
>> manual, then translate it into English)
>>
>> Ticket: https://github.com/okfn/opendatamanual/issues/19
>> Detail
>> --------
>>
>> Quite rightly, Linked Data has been raised in IRC:
>
> Question: which IRC network/channel do you use for these discussions?

#okfn irc.freenode.net

>> Despite this, I'm wary. I don't want to scare data providers away by
>> telling them that they need to start publishing wonderful RDF using
>> well established ontologies. That could add lots of cost and
>> complexity to an open data project.
>
> For what it's worth, a little semantics goes a long way. Linked Data IMHO
> does not automatically imply that you do _everything_ using RDF and
> established ontologies.
>
> What I think we should outline is the additional benefits that a Linked Data
> approach gives both publishers and consumers of open data, but also be
> upfront about the fact that (obviously) it requires more initial effort than
> just publishing a static CSV file.

+1

I think ScraperWiki.com could be quite useful here. It's possible to
create arbitrary views of datasets. This enables people to create RDF
versions of tabular data in an open source manner. An easy example
could appear in the manual. More complicated examples could be done
directly in ScraperWiki.

> Although to be fair, I don't think the effort in doing linked data is
> significantly more than the effort involved in developing your own custom
> API. It's more about unfamiliarity than about inherent technical complexity,
> IMHO.

This is a really good point. This seems like a great line of
reasoning: If someone is interested in spending a few hundred thousand
dollars on an open data platform anyway, then they should maximise
their returns by making something interoperable with everything else
in the Linked Data cloud.

>
>> Here are my thoughts on the target level (from the ticket):
>>
>> "The manual shouldn't attempt to be a complete text book on everything
>> related to Linked Data. It should attempt to explain the concepts in
>> broad detail, outline the benefits and be realistic about the
>> difficulties of the semantic web. We should provide pointers to
>> (ideally openly licenced) sources of further information."
>>
>> "Concepts such as RDF, OWL, SPARQL and so forth should be included in
>> the glossary."
>>
>> Do people agree with this?
>
> I think that is a fine starting point. There's a good book on Linked Data by
> Chris Bizer and Tom Heath, available for free online:
>
> http://linkeddatabook.com/book/
>
> Could be good source material to get some inspiration from, as well as a
> useful thing to point people to.

+1

>> Regarding the second point, and I hope he doesn't mind me saying this,
>
> Not at all :)
>
>> but one of the contributors of the Sesame* project, Jeen Broekstra is
>> a member of this list. He lives here in Wellington and will probably
>> be part of an informal semantic web/open data meetup group that I'm
>> helping to start. I invited him a few weeks ago to join. He's
>> expressed keen interest in assisting as time permits.
>
> Thanks Tim. "Time permits" is always a bit of cop-out, I know, but I can
> happily write some introductory blurbs and glossary entries in the coming
> weeks, at least as a first draft.
>
> Forgive the obvious newbie-questions (and feel free to tell me to RTFM),
> but: how do I get started, what format is preferable?

Short answer: email me any content you would like included and I'll
take it upon myself to get it into the manual.

Longer answer: we use reStructuredText, which is a little more
complicated than Markdown but far more flexible. We then use the
Sphinx documentation tool to compile this to HTML/LaTeX for us.
reStructuredText is a plain text format, so any editor should be fine.

Emailed content is fine. A plain text attachment to an email sent to
this list would well.

I am in the process of moving the old documentation to Githhub.
However, feel free to look at the "Our Tools" section of the
Participation Guide:
https://bitbucket.org/okfn/opendatamanual/wiki/Participation_Guide.
Naturally, content referring to Bitbucket and Mercurial is now out of
date.