I’ve read your post on using your own SPARQL endpoint to query other peoples RDF (http://blogs.cetis.ac.uk/wilbert/2010/03/12/meshing-up-a-jisc-e-learning-project-timeline-or-its-linked-data-on-the-web-stupid/), and it definitely started to feel like this was a more useful application of SPARQL than I’d seen before. I’m still not entirely clear – if I install my own SPARQL endpoint does that mean I can query any data that is available in RDF, or only that in a triple store?

I definitely agree with your comments about owl:SameAs (hadn’t realised there was a skos:similarTo but again, I definitely see the use). I’m less convinced about the statement “You use the same term for something slightly different? Not a big deal, I’ll just treat your graphs accordingly” – I’m not convinced this is as easy as you make it sound, and it indicates human intervention which I think starts to decrease the possible gains of using linked data. I probably need another post to expand on these concerns more fully.

Thanks for allowing me to think some of these issues through here…

One of the things that distinguishes the Linked Data technology stack from earlier Semantic Web approaches is the de-emphasis of the more rarified aspects of ontologies. What you use in LD is probably more accurately called vocabularies.

In practice, it’s the resilience in the face of abuse and different uses of such vocabs that convinces me most of RDF:
you use a different URI for the same thing? Fine, I’ll use owl:sameAs (or skos:similarTo)
I want to say something similar to what you’re saying, but be more specific? No problem, I’ll define my stuff as subclasses and subproperties from the ones you used
You use the same term for something slightly different? Not a big deal, I’ll just treat your graphs accordingly
You use some wildly different and convoluted vocabulary from me? If it’s worth it, I’ll just extract the info in my own terms using SPARQL’s CONSTRUCT

Unlike some other infrastructures, nothing breaks catastrophically; it’s just a matter of balancing effort with optimisation.

I think the BBC’s case illustrates perfectly where SPARQL is useful; if I want to mesh up the BBC’s data with other data, a SPARQL endpoint at the BBC is fairly useless. That just gives me answers about the BBC’s own data. If I want to meshup without constraints, I bring my own SPARQL endpoint and let that loose on their, and other people’s triples.

I could, of course, use other technologies to meshup data-with-URIs, but why would I? I can’t see any that are as mature, give as much choice, are as widely implemented/implementable or are as vendor independent as RDF + SPARQL (though oData is one to watch)

Lastly, with regard to the label thing, I think that it’s a simple categorisation issue, not a value judgment. A canal and a motorway are both worthy and useful pieces of transportation infrastructure, but recognising that fact doesn’t entail calling a motorway a canal. By analogy, there are many forms of Machine Readable Data infrastructures, of which Linked Data is just one.

Which kind of reminds me of the pirate code: “…the code is more what you’d call “guidelines” than actual rules…”

I think the description you offer is helpful, and I can see that without the relevant standards we don’t have Linked Data. However, I can also see how you could have ‘data which is linked’ by adopting http URIs as identifiers, but adopting other forms of data.

I can see the arguments against this – use RDF as it allows you to process stuff in standard ways, and agree on the ‘meaning’ of things using Ontologies. However, I’m slightly sceptical (although not entirely) about these arguments – partly because I suspect ontologies will quickly be abused (humans are going to be responsible for implementing ontologies, and they are going to get it wrong), and the processing argument comes down to where the cost is as far as I can see – but these are things I’ll try and pick up in another post.

The inclusion of SPARQL as a specified standard in the principles bothers me more than RDF. For example, the BBC publish ‘Linked Data’ as far as I understand it on a variety of pages, but they don’t provide a SPARQL endpoint (although the data is replicated in a Talis Platform store which does). I also feel it leads to the impression that the only way to interact with linked data is via SPARQL – whereas in terms of mashups, the benefit (I think) should come from share identifiers rather than anything else.

Sorry for the transposition of your name *blush*

I think that’s a nice and clear summary, but I think there’s also wider and simpler perspective. I think of it as the sandwich or layer view:

The bottom layer is composed of very diverse and rapidly expanding data sets in all sorts of formats; access and proper databases, spreadsheets, EXIF and other metadata, tables in Word files, PDFs etc.

The top layer is information that meets a particular audience’s need exactly, and is in a form that they are comfortable with (spreadsheets for accountants, groovy graphics for creative types, webpages etc.)

Linked Data is the middle layer: it describes how you get from any of the bottom layer data sets to any of the documents in the top layer.

In order for that to happen, bottom layer data must be available on the web for starters (i.e. Open Data), but it must also have a predictable form, give handles on its meaning, have a predictable form of transport, and you should be able to chop and change it in a predictable way.

That’s where the standards come in: RDF for form, URIs for meaning, http for transport and SPARQL for chopping and changing.

Ergo: no standards means no Linked Data.

To be sure, there are other ways to get from the bottom to the top, but they’re all partial and particular to one data type or tool. Getting from one such column to another means changing tool sets, learning new methods & tools & patterns and often lots of brittle hackery. Like BBSs before the web.

Does that mean that you have to have RDF to play in Linked Data space? Not necessarily: even if you don’t provide the RDF, someone else might convert your data for themselves or others. It just shifts the burden.