… are linksets today evaluated in an automated way?or does it depend on a person to interpret it?

Trying to answer this question here, but let’s step a bit: back in 2008, when I started to dive into ‘LOD metadata’ one of my main use cases was indeed how to automate the handling of LOD datasets. I wanted to have a formal description of a dataset’s characteristics in order to write a sort of middle ware (there it is again, this bad word) that could use the dataset metadata and take the burden away from a human to sift through the ‘natural language’ descriptions found in the Wiki pages, such as the Dataset page.

Where are we today?

Looking at the deployment of voiD, I guess we can say that there is a certain uptake; several publisher and systems support voiD and there are dedicated voiD stores available out there, such as the Talis voiD store and the RKB voiD store.

In our LDOW2009 paper Describing Linked Datasets we outlined a couple of potential use cases for voiD and gave some examples of actual usage already. Most notably, Linksets are used for ranking of datasets (see the DING! paper) and distributed query processing.

However, to date I’m not aware of any implementation of my above outlined idea of a middle ware that exploit Linksets. So, I guess one answer to Daniel’s question is: at the moment, mainly humans look at it and use it.

What can be done?

The key to voiD really is its abstraction level. We describe entire Datasets and their characteristics, not single resources such as a certain place, a book or a gene. Understanding that the links are the essence in a truly global-distributed information space, one can see that the Linksets are the key to automatically process the LOD datasets, as they bear the high-level metadata about the interlinking.

When you write an application today that consumes data from the LOD cloud, you need to manually code which datasets you are going to use. Now, imagine a piece of software that really operates on Linksets: suddenly, it would be possible to specify certain requirements and capabilities (such as: ‘needs to be linked with some geo data and with statistical data’) and dynamically plug-in matching dataset. Of course, towards realising this vision, there are other problems to overcome (for example concerning the supported vocabularies vs. SPARQL queries used in the application), however, at least to me, this is a very appealing area, worth investing more resources.

I hope this answers your question, Daniel, and I’m happy to keep you posted concerning the progress in this area.

Big confusion, right? Michael says one thing and then the opposite on the very next day. Nah, no really

Actually, turns out I’ve been quite consistent over time. In late 2008 I wrote in Talis’ NodMag #4 (on page 16):

Could you imagine reporting your new blog post, Wiki page or whatever you have to hand to an authority that takes care of adding it to a ‘central look-up repository’? I can’t, and there is at least one good reason for it: such things don’t scale. However, there are ways to announce and promote the content.

So, what is the difference between a UDDI-style registry (which, btw, not to exactly turned out to be a success) and, what I’ll call a central point of access (CPoA) in the following?

Before I try to answer the question, let me first give you some examples of CPoAs in the Web of Data context:

• Services that reconcile data from different sources, like uberblic.org
• Co-reference lookups, such as sameas.org;
• Generic Web of Data indexer such as the LOD Cloud Cache, Falcons or Sindice;
• A namespace/prefix lookup: prefix.cc;
• Ontology lookups such as Cupboard;
• ‘Single-dataset’ lookups such as DBpedia’s lookup service or the LinkedGeoData online access interface;
• Dataset description stores, such as the RKB voiD store.

Some of these CPoAs employ automated techniques to fill their internal databank (such as Sindice or sameas.org), some of them depend on human input (for example prefix.cc). Some of them focus on a special kind of use case or domain (Cupboard or voiD stores), some try to be as generic as possible (Falcons, Sindice).

All of them, though, do share one principle: it’s up to you if you’re listed there or not (ok, technically, some might discover your data and index it, but that’s another story). The (subtle) difference is a-prior vs. a-posterior: no one forces you to submit, say your voiD file to a voiD store or to Sindice. However, if you want to increase your visibility, if you want people to find your valuable data, want them to use it, you’ll need to promote it. So, I conclude: one, effective way to promote your data (and schema, FWIW) is to ‘feed’ CPoA. Contrast this with a centralised registry where you need to submit your stuff first, otherwise no one is able to find it (or, put in other words: if you don’t register, you’re not allowed to participate).

There are exceptions I’m aware of: DNS, for example, which works, I think, mainly due to its hierarchical aspect. Other approaches can be pursued as well, for example P2P systems come to mind.

Nevertheless, I stand by it: centralised, forced-to-sign-up registries are bad for the Web (of Data). They do not scale. CPoA, such as listed above are not only good for the Web (of Data) but essential to make it usable; especially to allow to bridge the term-URI gap (or: enter the URI space), which I’ll flesh out in another post. Stay tuned!

Basically, Daniel asked if it was not possible for every linked data publisher to follow a simple convention, that is to have the SPARQL endpoint available at common location such as /sparql – as Daniel found out, this is the case with most LOD datasets anyway these days.

Though the proposed good practice currently would be to publish a robots.txt that points to a semantic sitemap which in turn is the entry point for a voiD description, Daniel’s proposal is appealing. Simple and effective.

Additionally, it somehow reminds me on the /host proposal by Mark Nottingham and Eran Hammer-Lahav.

Thoughts, anyone?

This process might certainly be effective. You’ve gathered detailed information about 100 people and know precisely what they do and where they’re good at. Additionally, you’ve spent (or wasted?) 5000€ equivalent as it took you, say, a week? And I’m now just talking about gathering the data, not the tedious task of aggregating it nicely, formatting it properly so that you can use it to impress your sponsor.

Now, let’s imagine the same situation, but rather than you go and collect data, you ask people to provide their profiles themselves. All you do is set up a standardised form which contains fields for bio data, publications, projects, etc. and the people themselves provide this data by filling in the relevant fields. Then, after the deadline, you just press the ‘dump now’ button and voila, there you go …

Why am I telling this story? I guess this is mainly motivated by the fact that I am often faced with the question: why should one care about (using) voiD? With follow-your-nose (FYN), it is true that RDF offers a way to discover everything you like. If you’re not limited by time and/or budget. So, we note that this method is effective but NOT efficient,

To put it in other words, to a certain extent, FYN allows you to discover, gather and integrate all RDF-based data out there. It’s effective, but not very efficient. That is where voiD comes into play: people who have the data (or, at least know it very well provide a sort of summary of the dataset (regarding topics covered, license, vocabularies used, statistics on triples, interlinking, etc. as explained in the voiD guide). Then, all you need to do is operate on this summary. Using voiD, hence, for the task of discovery regarding the gathering, aggregation, and integration of data is effective and efficient, IMHO.

A machine that can be and actually is programmed. Ok, so we know that there is the data (yeah, TimBL, right, tell it them people: GIMME YOUR RAW DATA) and we are developer, right.

Let’s step back. May I quiz you a bit? So, tell me, Assembler:Java is like Web 2.0 programming:?.

My two cents are: the ? is a bunch of Web of Data technologies such as URIs, RDF, SPARQL, and now voiD. Rather than learning new APIs and proprietary formats based on XML or the like , one learns the RDF data model, then some vocabularies such as FOAF, SIOC, etc. and maybe some domain-specific ones. Then, one exploits linked data, that is the datasets that are already available on the Web, and starts developing her application.

Thoughts, anyone?