Perl implementation; Hypermedia RDF; More links

[Kjetil Kjernsmo]

Hi all!

I've newly subscribed to this list, and I suppose I know most of you
already, but for those who don't know me, I've sort of been around from the
start of LOD, as I took the initiative to and managed the SWEO Community
Projects back in the day, out of which the Linking Open Data project was
the only successful project. I've since then gone back to academia, and I'm
working on SPARQL query federation. Right now I'm working in the extension
of Görlitz & Staab's SPLENDID paper for those who are familiar with it.

Anyway, I have a few things, so this is going to be long. :-)

First, I just hacked a Perl module RDF::Generator::Void with the help of the
Perl+RDF community, mainly Toby Inkster. I've released some betas, the
latest includes class and property partitions and can be found here:
https://metacpan.org/module/RDF::Generator::Void
It has also entered Debian as librdf-linkeddata-perl, but as Debian has now
frozen for release, it is likely the previous beta that will be included
there: http://packages.debian.org/sid/librdf-generator-void-perl
I think this is important since it will put VoID on the boxes of many and
they do not have to provide security support for it themselves.

It can be deployed as part of my RDF::LinkedData module (which is, AFAICT,
the Pubby of Perl). The caching it can do is fairly primitive, so it can
probably not take large datasets. It works OK my own Norwegian Linked Data
site though, e.g. http://data.lenka.no/

Which brings me to the next thing I've done recently. On the LAPIS workshop
at ESWC, I presented a paper about hypermedia RDF:
http://folk.uio.no/kjekje/2012/hypermedia-rdf.pdf
slides at
http://folk.uio.no/kjekje/2012/lapis2012.xhtml

This is relevant to VoID, because inside, I advocate that VoID is important
to achieve hypermedia RDF. To create something RESTful with RDF, you need
RDF to be hypermedia. Basically, for RDF to be hypermedia, in many
practical applications you need to be able to get the vocabularies and you
may need to get to a SPARQL endpoint. TimBL already said that in his Design
Issue: "To make the data be effectively linked, someone who only has the
URI of something must be able to find their way the SPARQL endpoint.", but
AFAICS, the community hasn't taken the consequence of it.

To do it, every resource needs something like
<> void:inDataset [ void:sparqlEndpoint </sparql> . ] .
or if they *have* a VoID description, they need to link to it. From *every*
resource, or entity, whatever you want to call it. :-)

In RDF::LinkedData, I do this, as can be seen in e.g.
http://data.lenka.no/geo/inndeling/06/0627/data
(I'm also working on a implementation of the rest of the above paper, but
seldomly as it is too far from my dissertation topic). This is also in
Debian as librdf-linkeddata-perl, and an old version is in Ubuntu since
11.10.

I think the idea that every resource should link to the VoID description is
worth discussing in this group.

So, to my question (finally... :-) ):

I've been looking to add some void:TechnicalFeature stuff. Indeed, HTTP
caching Etags, because that's all I have. That's used as an example in the
Note, but I think it is most useful if somebody did mint a URI for that.
Has anybody done that?

The next question is similar: I link to Geonames from data.lenka.no, and I
was looking for a void:target URI, but it seems like everyone is minting
their own URI for this purpose? Isn't that evil? It would have much better
if I could really link to a Geonames Dataset, right?

Cheers,

Kjetil
--
Kjetil Kjernsmo
PhD Research Fellow, University of Oslo, Norway
Semantic Web / SPARQL Query Federation
kje...@kjernsmo.net http://www.kjetil.kjernsmo.net/

[Keith Alexander]

Hi Kjetil,

Thanks for all the pointers, very interesting.

> To do it, every resource needs something like
> <> void:inDataset [ void:sparqlEndpoint </sparql> . ] .
> or if they *have* a VoID description, they need to link to it. From *every*
> resource, or entity, whatever you want to call it. :-)

I think that would be good. I would say, from every document (where
the publisher chooses to publish multiple entity descriptions in the
same document).

>
> In RDF::LinkedData, I do this, as can be seen in e.g.
> http://data.lenka.no/geo/inndeling/06/0627/data
> (I'm also working on a implementation of the rest of the above paper, but
> seldomly as it is too far from my dissertation topic). This is also in
> Debian as librdf-linkeddata-perl, and an old version is in Ubuntu since
> 11.10.
>
> I think the idea that every resource should link to the VoID description is
> worth discussing in this group.
>

Probably most people think it's a good idea, but implementation in
real life seems patchy. I guess there are already quite a lot of
little details linked data publishers and tools have to take care of,
it is hard to implement them all. I don't know if any data consumption
tools use/expect a void:inDataset link?

> So, to my question (finally... :-) ):
>
> I've been looking to add some void:TechnicalFeature stuff. Indeed, HTTP
> caching Etags, because that's all I have. That's used as an example in the
> Note, but I think it is most useful if somebody did mint a URI for that.
> Has anybody done that?

Pass

>
> The next question is similar: I link to Geonames from data.lenka.no, and I
> was looking for a void:target URI, but it seems like everyone is minting
> their own URI for this purpose? Isn't that evil? It would have much better
> if I could really link to a Geonames Dataset, right?
>

I guess that would be up to the Geonames people?

Failing that, there are the lod-cloud.net URIs:
http://lod-cloud.net/dataset/geonames-semantic-web
or you could use a thedatahub.org URI (though these self describe with
dcat rather than void).

Best

Keith