Semantic Web, DataViewer

Why reading DataViewer pages instead of conventional web pages?

Yesterday Georgi Kobilarov asked this question reading this blog post about the DataViewer:

“could you elaborate on an example in which the Zitgist Browser / DataViewer enables me (the end-user) to do something I couldn’t do by reading web documents or even do something faster than by reading web documents?”

This is a good and legitimate question. However the first question would be: what Semantic Web documents (RDF documents) are used for? The idea was probably to gives the Web back to machines, so that they can have access and process the data more easily.

In such a vision, the use of such a DataViewer can raise some questions, as you did.

So, what is the usefulness of such a tool to end-users?

If you tell me that your home page contains the same information as the RDF document describing entities (and all the information about them) available from your home page, then yes, a human should read your home page more easily (since HTML documents are built for humans).

But one characteristic of RDF, and we can see it with the emergence of the Linking Open Data Community, is that data (entities) can be linked together, as webpage are.

Entities, so the data describing these entities, are meshed together. This means that my personal profile can be linked to the semantic web document describing the city where I live; it can also be linked to the articles I wrote; be linked to my friends and co-workers; be linked to the company I currently work for; to the projects I worked on and the ones I am currently working on; and so on.

All this information is accessible from one place: my personal profile semantic web document. All the other information is meshed and displayed in the DataViewer. So, instead of browsing all these web pages, you will have all the information displayed in a DataViewer page.

Given this vision of things, I envision that in the future people will craft data: describing things and linking things together, instead of crafting web pages. The data itself will drive the generation (and optimization) of user interfaces that will display that data.

The idea of the current DataViewer is simple: shapeshifting the user interface to maximize the display of meshed data. The same principles can apply to other systems such as emails clients, rss readers, web widgets, etc. What the DataViewer is, is a kind of semantic web data management system. What it produces, for the moment, is an HTML document. But I can assure you that you will see it incarnated in other services and in
other environments.

The DataViewer is not the answer to all problems of the World; however it tries to do one thing: managing the presentation of semantic web data to end-users. At the moment it takes the incarnation of a web page, but it the future it will be extended to other things. What is important is the principles, concepts and vision supporting the development of such presentation and management tools.

But we shouldn’t fool ourselves here: web page (HTML pages) have always been created, developed, crafter for humans. They are optimized for human understanding. An interface such as the DataViewer can’t compete with a will crafted web page. However it can do some things that web page can’t do if it has access to well crafted data sources. It can present, in a meaningful way, information that comes from a myriad of data sources, all in the same page, ready to gives immediately the information the user is looking for.

5 thoughts on “Why reading DataViewer pages instead of conventional web pages?

  1. Hi,

    Well, it seems to be working here. Could you tell me what information is missing? I quickly checked and it was looking good according to what was defined in the neutrophilic promyelocyte page.


    Take care,


  2. Well, I am probably interpreting the output incorrectly, but I would think that the SubclassOf reference would more or less encapsulate the class reference to promyelocyte (layered data, cfr.RDFa primer) and the restriction about the property, but it seems to mention the concept defined on that page instead. But nevertheless, great service…

  3. Yeah, in fact the thing here is that there is no templates yet defined for owl:Class (and owl:Ontology), etc. In such a case, the viewer use a more or less generic template (depends on cases) to create the document. So it explains the situation.

    However, as soon as we define templates to display ontologies stuff, then this case would be resolved.

    Take care,


  4. In response to Georgi’s question:
    “could you elaborate on an example in which the Zitgist Browser / DataViewer enables me (the end-user) to do something I couldn’t do by reading web documents or even do something faster than by reading web documents”ť

    My response:
    First, the current Document Web ultimately quantifies the number of documents (at a give point in time) containing relevant or irrelevant information (to me) that I will never find the time to read.

    An RDF Data Viewer such as the one from Zitgist, enables me to establish a bookmark in the Document Web from which to BEAM a Structured Data Query using a query language such as SPARQL (directly or indirectly).

    I can do this becuase the Data Viewer exposes the URIs of the Data Sources 🙂

    User Generated Content is growing exponentially at an ever increasing rate. Time remains a constant (24 hrs in a day). Thus, the sooner I can BEAM queries down the Giant Global Graph that is the Web, the sooner I return to my pursuit of being, or remaining, a realtime Netizen 🙂

Leave a Reply