Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Experiments in Linked Data


Published on

An overview of various private experiments to implement Linked Data using Ontopia.

Published in: Technology
  • Be the first to comment

Experiments in Linked Data

  1. 1. Experiments in linked data<br />Lars Marius Garshol, <><br />Topic Maps 2010, Oslo, 2010-04-15<br /><br />
  2. 2. What is this talk about?<br />Connecting across applications<br />using common identifiers for subjects<br />The applications are<br />tmphoto photo gallery<br />tmtools Topic Maps tools index<br />Larsblog my private blog<br />tmcase1 Naito-san’s index of Topic Maps talks<br /> the new Ontopia web site (not live yet)<br />
  3. 3. Why experiments?<br />I prefer to talk about real projects<br />but linked data has been hard to sell to customers<br />because the concept is hard to grasp?<br />because collaboration between organizations is hard?<br />because the market wasn’t ready yet?<br />anyway, there are very few projects so far<br />Therefore I’m showing some private experiments instead<br />the scale and complexity are limited<br />but it does demonstrate some of the potential<br />
  4. 4. A lightning tutorial<br />Identifiers<br />
  5. 5. Identifiers?<br />PSIs (Published Subject Identifiers)<br />a part of the Topic Maps standard, used for merging<br />a URI attached to a topic to identify it<br />the URI should refer to a page defining the subject<br />T<br /><br />
  6. 6. Name<br />Definition<br />
  7. 7. PSIs – things to note<br />Anyone can make a PSI<br />as long as they can publish content on the web<br />Domain names ensure PSIs are globally unique<br />only I make PSIs starting<br />PSIs can identify anything<br />if you can imagine it, you can make a PSI for it<br />
  8. 8. Starting with the first application<br />So, to the experiments<br />
  9. 9. tmphoto<br />Category<br />Person<br />Photo<br />Event<br />Location<br /><br />A topic map to organize my personal photos<br />contains ~15,000 photos<br />A web gallery runs on Ontopia<br />on<br />
  10. 10. You need more than one application to have true linked data. Data inside a single application is of course linked, but only in a trivial sense.<br />No linked data at this point<br />
  11. 11. tmtools<br /><br />Organization<br />An index of Topic Maps tools<br />organized as shown on the right<br />Again, web application for browsing<br />screenshots below<br />Person<br />Software<br />product<br />Platform<br />Category<br />Technology<br />
  12. 12. The person page<br />Boring! No content.<br />
  13. 13. And in tmphoto...<br />
  14. 14. get-illustration<br />A web service in tmphoto<br />receives the PSI of a person<br />then automatically picks a suitable photo of that person<br />Based on<br />vote score for photos,<br />categories (portrait),<br />other people in photo<br />...<br />The service returns<br />a topic map fragment with links to the person page and a few different sizes of the selected photo<br /><br />
  15. 15. get-illustration<br />Hmmm. Scores, categories, people in photo, ...<br />Do you have a photo of<br /> ?<br /><br />tmphoto<br />tmtools<br />Topic map<br />fragment<br />
  16. 16. Voila...<br />
  17. 17. Points to note<br />No hard-wiring of links<br />just add identifiers when creating people topics<br />photos appear automatically<br />if a better photo is added later, it’s replaced automatically<br />No copying of data<br />no duplication, no extra maintenance<br />Very loose binding<br />nothing application-specific<br />Highly extensible<br />once the identifiers are in place we can easily pull in more content from other sources<br />
  18. 18. How to choose common identifiers?<br />I was of course able to use the same PSI because I produced both datasets<br />But what if the two applications were maintained by different people?<br /> solves that problem<br />search on Subj3ct to find global identifiers for your subjects<br />
  19. 19.
  20. 20. Overview<br />tmtools<br />tmphoto<br />get-illustration<br />
  21. 21. Now what?<br />So far, so good<br />
  22. 22. My blog<br />Has more content about<br />people (tmphoto & tmtools),<br />events (tmphoto),<br />tools (tmtools),<br />technologies (tmtools)<br />Should be available in those applications<br />
  23. 23. Solution<br />My blog posts are tagged<br />but the tags are topics, which can have PSIs<br />these PSIs are used in tmphoto and tmtools, too<br />The get-topic-page request lets tmphoto & tmtools ask the blog for links to relevant posts<br />given identifiers for a topic, returns links to pages about that topic<br /><br />
  24. 24. get-topic-page<br />Do you have pages about<br /> ?<br /><br />Blog<br />tmphoto<br />Topic map<br />fragment<br />Topics linking to<br />individual blog posts<br />
  25. 25. In tmphoto<br />
  26. 26. Overview<br />tmtools<br />tmphoto<br />get-illustration<br />get-topic-page<br />blog<br />
  27. 27. Easy next steps<br />Topic pages on the blog must link to tmtools and tmphoto<br />trivial to do via get-topic-page<br />And the blog can use get-illustration, too<br />and so can and tmcase1<br />Oh, and they should link to the blog and the other applications...<br />
  28. 28. After a little hacking...<br />What a mess!<br />tmcase1<br />tmtools<br />tmphoto<br /><br />blog<br />get-topic-page<br />get-illustration<br />
  29. 29. We need a clean-up here<br />The get-topic-page service is generic<br />that is, it’s not tied to any specific application<br />further, the result set is a topic map fragment<br />Topic maps can be merged as we know<br />So, we could make a hub service<br />basically, a get-topic-page aggregator<br />
  30. 30. Client app #2<br />Client app #1<br />Client app #3<br />How it works<br />Hub service<br />blog<br />tmcase1<br />tmtools<br />tmphoto<br /><br />
  31. 31. Benefits of this approach<br />Much cleaner architecture<br />overview diagram no longer looks like a bowl of spaghetti<br />Easier to maintain<br />if I want to add/remove a service I do it in a single place<br />Safer<br />the hub service insulates clients from slow/unresponsive servers<br />
  32. 32. The result<br />
  33. 33.<br />Subj3ct is not just a database of PSIs<br />it also has links to pages with more information about the subjects<br />this can easily be wrapped in a get-topic-page service<br /><br />subjects<br />get-topic-page<br />Subj3ct<br />Wrapper<br />service<br />Client<br />
  34. 34. So we can add Subj3ct...<br />Client app #2<br />Client app #1<br />Client app #3<br />Hub service<br />blog<br />tmcase1<br />tmtools<br />tmphoto<br /><br />Subj3ct<br />
  35. 35. There is much more to tell<br />Unfortunately, 35 minutes is not very much<br />and this stuff takes some explaining<br />So I had to omit<br />sharing data with TMSync<br />manual reuse of data with the Ontopoly editor<br />...<br />Maybe next year<br />
  36. 36. Conclusion<br />Linked data is technically easy<br />conceptually and politically it’s harder<br />All you really need is<br />shared PSIs on your topics, and<br />someone to connect with<br /> is crucial<br />ensures that different players pick the same PSIs independently<br />without this there is no connecting...<br />