The Semantic Web or The Generic at War with the Specific
It's easy to imagine an application that takes advantage of Linked Data by extracting just what it needs and dumping it into a local relational database. But that's clearly cheating. It's equally easy to imagine a completely generic low-level Linked Data browser, but there's something less than completely satisfying about that, too. The basic problem is that a rich user experience requires specifics, while taking full advantage of the "anyone can say anything about anything" nature of the semantic web means that applications must be able to handle almost totally generic data[1]. At least that was the theme of my presentation to the Dallas chapter of the IxDA earlier tonight...
I'm especially proud of the way I failed to force people to sit through a detailed explanation of graph structures, subject-predicate-object triples, the use of URIs as identifiers, or any of the other traditional cruft that obscures the capabilities of semantic web technology under a morass of unnecessary detail. (Imagine introducing relational databases by first forcing people to understand index paging mechanisms, or learning to cook via an explanation of organic chemistry). The audience seemed to appreciate it.
[1] I struggled with this earlier over in /2009/03/linked-data-end-user-applications.html
[2] The translation from Keynote to Powerpoint to Google docs was not without problems. And you will definitely need to click through and get a larger version to read some of the screens.
I'm especially proud of the way I failed to force people to sit through a detailed explanation of graph structures, subject-predicate-object triples, the use of URIs as identifiers, or any of the other traditional cruft that obscures the capabilities of semantic web technology under a morass of unnecessary detail. (Imagine introducing relational databases by first forcing people to understand index paging mechanisms, or learning to cook via an explanation of organic chemistry). The audience seemed to appreciate it.
[1] I struggled with this earlier over in /2009/03/linked-data-end-user-applications.html
[2] The translation from Keynote to Powerpoint to Google docs was not without problems. And you will definitely need to click through and get a larger version to read some of the screens.
You should follow me on twitter here.
posted by cks at 8:37 PM
3 Comments:
Nice presentation but I think you left out a few solutions:
1. http://ode.openlinksw.com
2. http://virtuoso.openlinksw.com/dataspace/dav/wiki/Main/VirtSponger -- Sponger Middleware for making proxy Linked Data URIs (HTTP based Keys or Identifiers)
3. http://lod.openlinksw.com -- LOD Cloud Cache that provides powerful Lookup Service (DBMS is ultimately about views and lookups driving solutions)
4. http://virtuoso.openlinksw.com/dataspace/dav/wiki/Main/VOSSQL2RDF - RDBMS to RDF Linked Data mapping "on the fly"
5. FOAF+SSL which handles federated identity
6. http://tr.im/qoUL -- a presentation covering real problems solved by Linked Data .
Kingsley
Kingsley,
I left out more than just a few solutions! The focus was on (a) "on the web" solutions, I specifically left out middleware deep in the enterprise (vs "at the edge" stuff like in the BBC example) and (b) the examples were meant to be illustrative vs exhaustive, so I left out tons of stuff (some of which would doubtless have been better as examples than what I chose)
The slides are a little misleading about the "Linked Data" thing, too. We actually discussed which of the solutions obeyed which of the Linked Data principles to what degree (although I didn't explicitly enumerate them). For example, Tabulator is hard-core pure Linked Data (since it browses out through links live), while other solutions might do things like share common URI identifiers but maybe cache locally instead of dereferencing the URIs live (and also include non-RDF data sources) Batch-caching weakens the Linked Data value proposition (since the referenced data is no longer "alive" in a very real sense, at least until the next batch update), but may be the only practical way to go. I actually don't know the BBC's caching strategy, it was more a jumping off point for an inline discussion of tradeoffs of doing this stuff in real, live production applications.
Thanks for the feedback and links!
Hmm. don't really grok "hard core". Likewise, based on your definition of "hard core Linked Data", I don't see how that eliminates any of the items listed :-)
I think OpenLink is as hard core as you get re. Linked Data :-)
Re. middleware, the sponger is about middleware for the Web that uses URIs as medium of value exchange.
I know what you are trying to do, and I am trying to make your message a little clearer by referencing tools that solve real problems (i.e., not research projects).
Linked Data is all about separation of presentation, representation, identity, data access, and data storage.
The statement above is why its value prop. comprehension can be mercurial i.e., it isn't explicitly about any one of the items listed, its about all of them within relevant context.
The Linked Data meme is about implicitly binding an Entity to its Metadata via an HTTP based URI. That's it, one sentence describing a solution to many aged old computer industry problems courtesy of HTTP.
The problems are:
1. Identity (people, place, and other things)
2. Data Access
3. Data Integration
4. Data Storage
5. Security via policies applied to items 2-4.
Very important to note, Linked Data is about innovative use of HTTP to deliver on earlier failed promises in the realm distributed data objects (referencing and de-referencing data using network wide pointer system).
Kingsley
Post a Comment
<< Home