A user friendly way to explore and view Linked Data
Available to try at linksailor.com
Predecessor was Dipper, an application that ran wholly in the browser (written in Javascript) that could browse data held in the Talis Platform.
I wrote it to learn how to build in-browser, AJAX driven applications.
Dipper employed a number of techniques to increase effectiveness of the information presented:
Dipper was designed as an in-browser application which brings several architectural advantages:
Dipper had several limitations that made it unsuitable for wide use:
Linksailor was an entirely new creation that took the learnings from Dipper and attempted to overcome them to become a more general purpose utility.
I wrote the bulk of the code in my spare time during the autumn of 2010 and publicly released it at linksailor.com that Christmas.
I wanted to resolve the disadvantages of Dipper while retaining the architectural model as far as possible.
The standard web browser model involves the user manually hunting for information by clicking links.
Linksailor inverts this by gathering information on behalf of the user using the relationships in the underlying data.
Linksailor adheres to a set of underlying design principles:
Focus on viewing the real-world things of interest to a user.
Present descriptions of the primary resource plus related things in lesser detail to give the general context.
Use the structured nature of the underlying RDF data to make decisions.
Select appropriate views and behaviours based on the types and relationsips in the data retrieved.
Reach out and explore the graph to discover additional relevant data.
Discriminate the data shown to the user.
Remove or hide noisy, irrelevant and repetitive data.
Showing too much data decreases utility.
Allow new types of views, behaviours and data sources to be added easily.
Provide a core framework that can be enhanced by third parties.
Linksailor consists of a client component which runs in the browser, complemented by a server component which mediates access to remote data sources.
Packages and delivers client component code to browser.
Proxies data requests to remote sources.
Dispatcher uses VoiD registry to look up SPARQL endpoints.
URI Resolver fetches content or queries and parses results (RDF, XML, RDFa etc).
Layout engine and scheduler run in infinite loops.
All data received is stored in in-memory graph.
Plugins selected based on graph patterns.
Plugins query and extend graph.
All requested data comes from server as RDF.
Graph grows as plugins request more data.
Discarded when primary resource changes (new page).
RDF/JSON is used so virtually no parsing is needed in client.
Patterns look for:
More sophisticated paths would be a good enhancement.
May request additional data needed:
Each plugin selected by layout engine will generate more requests for data.
Data added to the graph triggers layout engine to rescan plugins.
New data may select additional plugins which are then rendered and may generate yet more data.
Plugins generate a lot of requests for data.
20-30 on average, sometimes 1000+
Lightning fast due to browser net stack and cache.
Requires throttling, can overwhelm browser since they limit number of concurrent requests.
Plugins consist of:
Page is layed out automatically on a simple grid.
Primary, secondary and related plugins for themed presentations of information.
Looks for largest description and picks a related image.
Clustered by property, grouped by theme (e.g. identifiers).
Large lists are paginated automatically, also limited to threshold.
Map is automatically zoomed to local level.
Lower zoom, shown when primary resource has a geo location.
Shown when more than two geographic points are found in data.
Generated from UPC/EAN/GTIN information.
Experimental use of Google charts.
Generated based on knowledge of sparql endpoint to query.
Table generated from multiple properties.
Images link to related resources.
Revamping and streamlining widget system.
Updating main framework to use extensible components such as backbone.js and mustache.js.
Enabling community sharing of plugins.
A number of different possible directions for Linksailor.
Several different configurations plus some research areas.
Contact me directly if you are interested in developing Linksailor for your organisation <nospam@iandavis.com>
One-click deploy to any site.
Enable theming and branding of the pages.
Configure for a single primary dataset plus optional enrichment from the LOD cloud.
Re-use plugin system to enable creation of dashboards.
Enable fixed and persistent layouts.
Would need to relax resource-oriented design principle.
Enable plugins to be embedded on any website.
Enhance blogs and other websites with dynamic information.
Triple store cache on server, with reasoning support.
More expressive pattern language for plugins.
Pattern evaluation against entire web (as per linkpath.
Interactive widgets, dynamically fed with data.
Contact
Ian Davis <nospam@iandavis.com>
Permanent link
http://iandavis.com/pres/linksailor/
Licensed under
Creative Commons Attribution 3.0 Unported License
Permanent link to this presentation:
http://iandavis.com/pres/linksailor/