RKB Blog

<executive_summary>

“If you consume open data you should publish as open data.”
I’m going to call this Principle 5, as things need to be named, and also of course give it a URI: http://www.rkbexplorer.com/blog/?p=33

What am I talking about?

In the bright new world, there will be lots of data from government (and elsewhere) out there for others to consume. Much of the discussion of this list is to advise the owners of that data to publish it in a way that makes it easily accessible.
However, we should remember that every time some of that data gets consumed, new data is generated. And the people who have generated that data should feel similar or greater pressure of obligation to publish as open data to that pressure applied to the publishers of the data they consumed.

One might say: “What’s sauce for the goose is sauce for the gander.”

</executive_summary>

Of course many people already do this, but I think it is worth pointing it out as people start to build more systems that consume.
It is quite easy to build a system that publishes, as long as it is designed in from the start; on the other hand, having built an intricate web page, it can be incredibly time-consuming and even very difficult to add on the data publishing facilities later.

As a simple example of what I mean, let’s take a site that consumes education data, and tells you a little bit about it, perhaps by showing a map where I can click on an area and find out how many kids go to school there.
Does the site publish URIs for each of these statistics?
Is it easy to find these things, or do I need some complex API?
Can I get a dump of the whole dataset?
What formats are offered?
Are there interesting html fragments that someone else might use?
Is the license clear?
Even, is there a SPARQL or other querying endpoint?

I think quite often a consumer who does something like this doesn’t really think they have generated much data, and so doesn’t engage with publishing; but each step along the way adds value, and they should celebrate the fruits of their labours by making them easily accessible.
Even taking some data and doing a nice html rendering can be really useful
to someone who just wants to add something interesting to their own page.

This leads to another issue on dataset directories.
We should not consider it satisfactory just to list the source datasets:- we should consider everything a source, and so try to record a graph of dataset derivation.

Finally, why call it Principle 5?
That relates to Linked Data – there are four principles at the moment:- I happen to think that this is so important that Tim might decide to add it as a fifth principle: “If you consume Linked Data, you should publish as Linked Data”.

As they say, my 2 cents worth.
Best
Hugh

1. Create a web-accessible directory with all your .rdf, .ttl, .ntriples and .html files in it.
2. Copy lodpub.php and path.php into it.
3. Access path.php from your web server.
4. Follow the instruction to paste that text into .htaccess
5. You can remove path.php, it was only there to help you get the .htaccess right.
   

lodpub.php
path.php

François Scharffe <francois.scharffe@inria.fr> asked us, so this is what I responded.

Here is a description of what we do in English.

The implementation may vary, but this is the rough idea.

It is really quite simple, I guess.

We are primarily concerned with organisations, people, publications, projects, research areas.

Research areas we have done by hand against relatively fixed ontologies.

Organisations and projects work in similar ways top publications, but I will do the publications bit.

1) To start with, there is absolutely no linkage, so we do a “coldstart”, and this is done on paper titles only.

Extracting all the strings/uri pairs from all the KBs, we map the title to lower case strings of the alphanumerics; if the result is sufficiently long (>=20) and identical, then the uris are considered the same (”smushed”).

2) Now we can work on authors (string matching out of context would be too liberal). For the same (co-reffed) papers, the authors are fuzzy matched (cross product).

3) For each author string name, we find the co-authorship sets for each paper (we do this by starting with a each unique name, to make it easier).

If there is an overlap of two or more co-author strings between different sets, then these authors are smushed.

The matching of names for this is not fuzzy, but does match name variants, as identified by previous co-ref work on the URI for the author name we are looking at.

(Another way of looking at it is that if we find three authors of the same name as paper authors, we smush them.)

Also, if there are exactly two author with similar names, then we smush them.

4) The rest is dynamic. As users browse the data at rkbexplorer.com, we compute networks (communities of practice of closely related entities by domain-specific weighted RDF predicate). If strings are similar in the network, then they are smushed.

This sort of should be the first posting, I guess.

A new blog where we can out stuff about RKB, sameAs.org, etc.