bobdc.blog

The first ever Linked Data conference, sponsored by Jupiter Media at New York City's Roosevelt hotel last Tuesday and Wednesday, was great. I didn't give any talks, but as co-chair I put together the program with Ken North and with his throat bothering him a bit I did most of the speaker introductions. I also moderated the Linked Data Workshop panel, a session that provided the audience with a good range of perspectives on some difficult Linked Data application development issues such as data access control and the use of distributed versus aggregated data.

The Linked Data movement is just the latest step in this long process that began almost fifty years ago of separating data further and further from the programs that create and maintain it so that other programs can use it, opening up new possibilities along the way.

In addition to seeing some old friends, I got to finally meet many people I had only known by email or reputation, such as Kingsley Idehen (who first had the idea for the conference), Seth Earley, Christine Connors, Taylor Cowan, Andy Seaborne, Barak Pridor, Ashok Malhotra, Dean Allemang, Jim Hendler, Paul Miller (the voice of the Talking with Talis podcasts, whom I've heard interview most the people named in this sentence), and especially Tim Berners-Lee, whose keynote Tuesday evening was quite an inspirational pep talk for the Linked Data movement. Unlike some other big name keynoters I've seen, he didn't just fly in, give his talk, and fly out; he attended and closely followed a great many talks. (In fact, when a group of conference organizers and keynote speakers met in the hotel bar before heading off to a prearranged dinner, we couldn't find the main keynote speaker, and it turned out that he was attending an evening panel on the business possibilities of the semantic web. Luckily, he managed to catch up with us.)

An interesting point in his keynote was how the original web made computers less important, and documents more important—for example, if I want to see a given spec or read a particular story, I don't care what computer it's on—and how Linked Data principles will help make documents less important and data more important. I didn't understand this at first, but then realized that if I want to know a convenient start time for a movie or some good flights to get me from one city to another, I don't care what document these facts are stored on; I just want the data. In fact, I want to easily find or write a program that grabs that data without relying on a proprietary data format or scraped HTML. The Linked Data movement is getting us there.

Uche Ogbuji's talk on Linked Data: The Real Web 2.0 described something interesting that he didn't mention in his interview here shortly before the conference: his company Zepheira's concept of "Linked Enterprise Data", or LED. With so much Linked Open Data talk out there about the value of freely sharing data across the web, this uses the same principles for different means: easier sharing of data across the silos behind a firewall through the use of Linked Data principles. As one of Uche's slides put it, "Rather than the ERP-type play to replace legacy apps with a centralized super-model, LED focuses on wrapping and exposing data in those apps".

I like this for two reasons. First, it's a nice application of the database tuning world's appropriation of the classic political advice "think globally, act locally". Second, it works toward using Linked Data principles to solve current business needs instead of just treating it as some variation on the semantic web that could lead to cool applications.

Ken's opening welcome address helped put Linked Data into the perspective of the long-term history of computing (Ken knows a lot about this stuff), and this gave me a new insight: the original "data base" managers (or, even, in those days, "data bank" programs) were a step forward in the history of computing because they separated the data from the application that created and used that data so that other programs could use it. The Linked Data movement is just the latest step in this process that began almost fifty years ago of separating data further and further from the programs that create and maintain it so that other programs can use it, opening up new possibilities along the way.