• Friendfeed
• Twitter

Enjoy!

The Web Universal Plug and Play (WUPnP) Cheatsheet:

Essentially, if you build an application and use the technologies suggested in the ‘glue section’ then your web application/service (whether it’s front-end or back-end) will fit into many many other web applications/services… and therefore also more manageable for the future! This is WUPnP.

Key technologies for making your services/applications as sticky as possible:

• Dereferenceable URI’s (which indicate HTTP networking)
• OpenID
• OAuth
• SPARQL
• Linked Data RDF (or RDFa) and OWL

Web-based plug and play fun!

(Via Daniel Lewis.)

Naturally, we've decided to join the Crunchbase RDFization party, and have just completed a Virtuoso Sponger Cartridge (an RDFizer) for Crouncbase. What we add in our particular cartridge is additional meshing with DBpedia and Wikicompany Linked Data Spaces, plus RDFizaton of the Crunchbase (X)HTML pages :-)

As I've postulated for a while, Linked Data is about data "Meshing" and "Meshups". This isn't a buzzword play. I am pointing out an important distinction between "Mashups" and "Meshpus". Which goes as follows: "Mashups" are about code level joining devoid of structured modelling, hence the revelation of code as opposed to data when you look behind a "Mashup". "Meshups" on the other hand, are about joining disparate structured data sources across the Web. And when you look behind a "Meshup" you see structured data (preferably Linked Data) that enables further "Meshing".

I truly believe that we are now inches away from critical mass re. Linked Data, and because we are dealing with data, the network-effect will be sky-high! I shudder to think about the state of the Linked Data Web in 12 months time. Yes, I am giving the explosion 12 months (or less). These are very exciting times.

Demo Links:

• Opera Software via Benjee's Linked Data Space for Cunchbase
• Opera Software via our Linked Data Space for Crunchbas

For best experience I encourage you to look at the OpenLink Data Explorer extension for Firefox (2.x - 3.x). This enables you to go to Crunchbase (X)HTML pages (and other sites on the Web of course), and then simply use the "View | Linked Data Sources" main or context menu sequence to unveil the Linked Data Sources associated with any Web Page.

Of course there is much more to come!

I've just digested Nova's post announcing the opening up of Twine. My test was simple, I opened up his Twine page using Firefox (with the new OpenLink Data Explorer extension in place), and then simply executed the following browser menu sequence:

1. View
2. Linked Data Sources

And voila! The Twine page morphs into a Linked Data Space where each entity presented is endowed with dereferencable URIs; enabling me to traverse and/or Mesh his data with other Linked Data Spaces such as mine, for instance.

This is what Linked Data is all about! The fun has only just begun :-)

My use of "old media" implies: a place that still seeks subscriber data (no OpenID etc..), for the umpteenth time, as the toll fee for discourse development and participation on the Web.

Anyway, here is what I attempted to post as a comment to Dan Grigorovici's post titled: Where is the Semantic Web Killer App?

Dan,

An intriguing post to say the least :-)

"Linked Data" and "Semantic Web" aren't synonymous, they are simply connected, infrastructure DNA-wise. You can have "Semantic Web" style graphs (i.e RDF Data) and not have "Linked Data" as per Linked Data deployment tenets and best practices, a very important point.

I've stated repeatedly, the "Linked Data" emphasis has more to do with focusing on a point of crystallization within the larger "Semantic Web" vision, so here is a quick recap:

What is Linked Data?

A term coined by TimBL that describes an application of HTTP to the time-tested process of "Data Access by Reference". "Linked Data" adds vital items to the "Data Access by Reference" pattern that have been erstwhile unattainable:

• The use of a Data Source Naming scoped to Database / Data Container Records as opposed to Tables, Views, Stored Procedures, Databases, and other Record Container tuple collections. Example: in ODBC / JDBC, a Data Source Name's scope stops at the Table / View level. In the Linked Data realm you get an added layer of granularity due to record level name scope
• Incorporation of HTTP into the Data Source Naming scheme, which injects the expanse of the Web into the Data Access Range of the Data Source Name (i.e. a Named Record); so you can reference a record's description directly via HTTP which is simply a major deal (to put things mildly).

So we have HTTP based URIs as the Data Sources Names for a "Linked Data Web" i.e a Web of inter-connected Data Source Names that de-emphasize the importance of their host containers (Compound Documents / Information Resources).

The business case or value proposition of "Linked Data" is synonymous with the value proposition of data access technologies such as ODBC, JDBC. ADO.NET, OLE-DB, XMLA, and others (enterprise or consumer) in relation to the Individual and Enterprise pursuit of agility; in a realm where data is growing exponentially, and the maximum processing time in a single day remains 24 hrs. Data Access & Data Integration are timeless challenges due to the following constants:

• Structured Data Schema Heterogeneity - we will always model the same things differently
• Dirtiness of Data within Structured Data Containers - we are error prone due to laziness / sloppiness, time constraints, and the inherent limitation of our DNA based CPUs when dealing with large volumes of data.

Note: The line between the Enterprise & Individuals continue to blur by the second, this is something I covered during my Linked Data Planet keynote, which is like most things I put on the Web (via this blog data space), is a live and practical demonstration of the virtues of Linked Data courtesy of RDFa, the Bibliographic Ontology, and dereferencable URIs (i.e. HTTP based Data Source Names for Documents and the Entities they host).

Related

• Linked Data FAQ - by Mike Bergman
• The Planetary Computer from Wired Magazine - which is basically the effect of Linked Data under a different label (note to Wired: "Tired of old Media repetitive Registrations" when seeking to make comments in the OpenID era!).

I would tweak of the law modification expressed in Mike Bergman's post which states:

the value of a Linked Data network is proportional to the square of the number of links between the data objects.

Channeling Einstein

How about Einstein's E=mc²? I am talking Energy (vitality) and Network Mesh equivalence, where "E" is for Energy, "m" for Mesh (i.e. Network Mesh where each node contains sub-particles that are themselves network meshes all endowed with typed links and weightings), and "c" is for computer processing speed (processing speed is growing exponentially!). When you beam queries down a context rich mesh (a giant global graph comprised of named and dereferencable data sources), especially a mesh to which we are all connected, what do you get? Infrastructure for generating an unbelievable amount of intellectual energy (the result of exploding the sub-data-graphs within graph nodes) that is much better equipped to handle current and future challenges. Even better, we end up making constructive use of Einstein's findings (remember, we built a bomb the first time around!). TimBL articulates this fundamental value of the Web in slightly different language, but at the core, this is the essence of the Web as I believe he envisioned; the ability to connect us all in such a way that we exploit our collective manpower and knowledge constructively and unobtrusively, en route to making the world a much better place :-)

Note: None of this in incongruent with being compensated (i.e. making money) for contributing tangible value into, or around, the Mesh we know as the Web :-)

Related

• Business at the Speed of Thought - by Bill Gates
• Blink - by Malcolm Gladwell

Enjoy!

URIs are simple to use i.e you simply click on them via a user agents UI. However, URLs when incorporated into Data Source Naming en route to constructing HTTP based Identifiers, that deliver HTTP based pointers to the location / address of a Resource Descriptions, another matter.

I touched on this issue in my Linked Data Planet keynote last week, and I must say, it did set off a light.

I believe, we can only get the broader Web community to comprehend the utility of URIs (Web Data Source Names) by exposing said utility via the Web's Universal Client (Web Browser). For instance, how do URN based Identity / Naming schemes help in a world dominated by Web Browsers that only grok "http://"? From my vantage point, the practical solution is for data providers who already have "doi", "lsid" and other Handle based Identifiers in place, to embark upon http-to-native-naming-scheme-proxying.

In my usual "dog-fooding" and "practice what you preach" fashion, this is exactly what we do in the new Linked Data Web extension that we've decided to reveal to the public (albeit late beta). Thus, when you use an existing browser to view pages with "lsid" or "doi" URNs, you still enjoy the utility of getting at the "Raw Linked Data Sources" that these names expose.

The keynote: Creating, Deploying, and Exploiting Linked Data, sought to achieve the fundamental goal of: Demystify the concept of "Linked Data" using anecdotal material that resonates with enterprise decision makers.

To my pleasure, 90% of the audience members confirmed familiarization with the "Data Source Name" concept of Open Database Connectivity (ODBC). Thus, all I had to do was map "Linked Data" to ODBC, and then unveil the fundamental add-ons that "Linked Data" delivers:

• The ability to give database records names (Identifiers)
• The use of HTTP in the database record naming mechanism - which expands a named database record's reference scope via the expanse of the Web (i.e HTTP based Identifiers called URIs).

I believe a majority of attendees came to realize that the combination above injects a new Web interaction dynamic: access to "Subject matter Concepts" and Named Entities contained within a page via HTTP base Data Source Names (URIs).

BTW - My presentation is a Linked Data Space in it's own right courtesy of the Bibliographic Ontology (which provides slide show modeling) and RDFa that allows me to embed annotations into my Slidy based presentation :-)

Related

• PowerPoint version of Presentation
• Slideshare hosted version
• Authorstream hosted version
• Google Docs hosted version

First up, the Library of Congress, take a look at the following pages which are "Human" and machine based "User Agent" friendly:

• Science
• Humanities
• Mathematics
• Cataloging
• World Wide Web

You can see a tabulated view of all of the above, with associated links to RDF Browser views, at the Library of Congress Subject Headings home page. This neat of piece of Linked Data artistry has be put together by Ed Summers.

Note: The pages above are served up in line with Linked Data deployment and publishing tenets espoused by the Linking Open Data Community (LOD) which include (in my preferred terminology):

• Giving "Names" to things you observe (aka Data Source Names or "DSNs" for short)
• Use HTTP URLs in your data source naming scheme so that "access by reference" to your data sources exploits the expanse of the HTTP driven Web i.e make your DSNs "Linked Data Source Names" (LDNS)
• Remember that Documents / Pages are compound in nature, and they aren't the only data sources we would want to name; a document's LDSN must be distinct from the LDSNs used for the subject matter concepts and/or named entities associated with a document
• Use the RDF Data Model to express structure within your data source(s)
• Use LDSNs when constructing statements/claims/assertions/records (triples) inside your structured data sources
• When publishing Web Pages related to your data sources; use at least one of the following to methods to guide user agents to data sources associated with your published page; the HTML LINK tag, RDFa, GRDDL, or Content Negotiation.

The items above are features that users and decision makers should start to hone into when seeking, and evaluating, platforms that facilitate cost-effective exploitation of the Linked Data Web.

As you can see from my recent post about how we've started the process of inoculating DBpedia against the potential dangers of "contextual incoherence", we are entering a newer era in the Semantic Web's evolution. My post and the one from Clark & Parsia both touch different aspects of the "Data Dictionary" for the Semantic Web issue.

Note: in my universe of discourse, a Data Dictionary manifests when the constraints and class hierarchies defined in an ontology (e.g. a web accessible shared ontology) are functionally bound to a data manager. Interestingly the binding can take the following forms:

• Engine Hosted - which is what you get with Virtuoso's in-built Inference Engine
• External - which is what you get when the Inference Engine is a distinct component from the data manager (example: Owlgres which can sit in front of 3rd party SPARQL endpoints via ARQ)

The classification terminology I use above is very much off-the-cuff, its sole purpose is architectural distinction.

Anyway, it's really nice to see that we are entering an era re. the Semantic Web vision, where the virtues of reasoning are getting simpler to demonstrate and articulate.

In a nutshell, the point-point data integration era is coming to an end! The era of intelligent ontology based enterprise data integration is nigh!

Of course, there is much more to come on the practical utility front, so stay tuned as we work our way through the DBpedia inoculation program.