This paper introduces a Linked Data application for automatically generating a story between two concepts in the Web of Data, based on formally described links. A path between two concepts is obtained by querying multiple linked open datasets; the path is then enriched with multimedia presentation material for each node in order to obtain a full multimedia presentation of the found path.
Interconnectedness is a major topic discussed in philosophy and physics,
stating that everything in the world is connected in some way. A
popular example is the Six degrees of Separation principle, introduced by S.
Milgram [
This demonstration relies on Linked Data to illustrate the above described principle (i.e. interconnectedness) by following machine-processable links within today's Web of Linked Data. The presented application will retrieve the connection (with intervening nodes) between two given concepts. Next, for each resource corresponding to a node in the found path, a media presentation is generated (e.g. use of a photo to illustrate a person). Finally, the found path is narrated through a full multimedia presentation, illustrating the intervening resources and their connections (i.e. the links). The aim of this demo is therefore threefold: { bringing Linked Data closer to inexperienced users; { a practical test of the link quality in today's Web of Data; { investigate query/browse strategies for distributed path retrieval.
The goal of the demo is to automatically generate a story between two concepts, based on formally described links. We obtain such a story in three steps: path generation, node illustration, and path presentation. 2.1
Path generation is based on querying Linked Data sources. In this demo, we consider the following linked datasets to obtain a path: DBpedia, Facebook, Freebase, Wiktionary, WordNet, CIA Factbook, Eurostat, GeoNames, MusicBrainz, linkedMDB, and New York Times. DBpedia serves as the interconnection hub between the other datasets; using Facebook adds a personalized touch to the application. Note that we use standard Named Entity and Disambiguation (NERD) techniques to link output from the Open Graph Protocol to DBpedia resources. Also note that we assume that the two input concepts (i.e. the start- and endpoint) are located within our prede ned list of data sources.
Since we do not want to load all our datasets into one RDF store for scalability reasons, we introduce progressive parallel link browsing. The latter tries to nd paths between two resources by combining the following tasks: (1) nd a path between the start resource and a DBpedia resource (DBpedia start resource); (2) nd a path between the end resource and a DBpedia resource (DBpedia end resource); (3) nd a path between the DBpedia start resource and the DBpedia end resource (either inside DBpedia or via another dataset). This approach enables parallel execution by making the rst task independent from the last. Also, since the nodes in the path are discovered sequentially, progressive playback is possible during discovery. The choice of which links to follow is crucial in nding meaningful paths for the end-user. Therefore, a property prioritization mechanism is introduced. Certain properties (such as rdfs:seeAlso, foaf:primaryTopic, dbpedia:wikiPageWikiLink) contain little semantics in order to explain the link between two resources. Further, following rdf:type or dcterms: subject might result in links that are too general (e.g. both resources are owl:Things). However, when the type is speci c enough (e.g., Category: FC_Bayern_Munich_players), it can be an interesting link. Therefore, a priority list is needed indicating which properties and classes/categories should be avoided during querying. Note that these `blacklists' might still be used in fallback scenarios when the original attempt did not give any result. 2.2
Given a path between start and end resource, illustrations of the nodes need to be found in order to enable a path presentation (see further). These illustrations can be text, video, audio or images. A rst attempt to provide a human-readable representation of a resource is to follow your nose: lookup the RDF properties of the resources and search for illustrative properties: { text: rdfs:label, dbpedia-owl:abstract, rdfs:comment, ...; { image: foaf:depiction, dbpprop:picture, lode:illustrate, ...; { video/audio: lode:illustrate, ...
Alternatively, we use Web services to look up images (e.g. Flickr, Google Images, Bing Images, ImageNet), videos (e.g. YouTube, Vimeo), and audio (e.g. Grooveshark) to provide illustrative material for the resources. 2.3
As a nal step, we present the retrieved path by means of a multimedia presentation with voice over. This requires a uent narrated story, assembled from two types of data: topic descriptions and links. Topic descriptions are pieces of text fetched from certain RDF properties (see previous section) and give a short summary about the current topic. Links between nodes glue these pieces together into one story. However, narrating links is more di cult, since there is no descriptive text available. Di erent approaches are possible: from a simple display of the property label (e.g. dbpedia-owl:birthDate becomes `has birth date') to a property-speci c illustrator. The current version of the demo is limited to the simple property label approach.
Using the Acapela text-to-speech service1, we are able to provide a voice over narrating the textual representation of nodes and links, making the multimedia presentation complete. 3
The application runs on a classic client-server architecture where the path generation step is executed on the server, while node illustration and path presentation are performed at the client (i.e. in the browser). A number of performance optimizations were implemented: { where possible, queries during the path generation are run in parallel; { when parts of a path are found, these are already send back to the client; { the client will run the node illustration tasks in the background (i.e. during presentation of the rst nodes, information about the following nodes will be fetched). 4
In order to illustrate the idea, we will connect the dummy Facebook user John Doe to Chicago. Using the Facebook Open Graph protocol, we nd out that he likes David Guetta (ogp:userA ogp:likes dbpedia:David_ Guetta). By looking up dbpedia:David_Guetta, we nd his birthplace to 1 http://www.acapela-vaas.com 4 be Paris (dbpedia:David_Guetta dbpprop:birthPlace dbpedia:Paris). We derive from this resource that it is the location of the Ei el tower (dbpedia:Eiffel_Tower dbpedia-owl:location dbpedia:Paris). One of the designers of the Ei el tower was Emile Nouguier who died in 189802-20 (dbpedia:Emile_Nouguier dbpedia-owl:significantBuilding dbpedia:Eiffel_Tower; dbpprop:deathDate \1898-02-20"). The latter is also the birthdate of Jimmy Yancey, who died in Chicago (dbpedia: Jimmy_Yancey dbpprop:birthDate \1898-02-20"; dbpprop:deathPlace dbpedia:Chicago.).
A screencast of the Everything is Connected application is available at http://youtu.be/FawygFT5Brs. In this screencast, we show the resulting multimedia presentation for the above described example. Multimedia content showed in this example comes from Google Images, Google Maps, and YouTube. 5
Concerning path generation, some work is done in the eld of Social
Network search. Given the degrees of separation principle, [
For the Path presentation, QWiki2 produces similar output. However, this tool is limited to turning any concept found on Wikipedia into a automatically narrated multimedia presentation based on the Wikipedia abstract.