Thursday, September 25, 2008

Semantic Web and smart clients

Few days ago, I attended a conference organized by the group “Rencontres d'Architecture de Montréal” [1], non-profit organization I am a co-founder of. The presenter was James Lapalme and his talk presented the Semantic Web concepts [2]. He introduced the basics, explains the different layers and standards (RDF, OWL, SPARQL, etc.), and presented a tool he uses [3].

Here is his presentation:

The audience was diverse: enterprise architects, solution architects, data architects, infrastructure architects. All attendees gave an excellent feedback, and all of them went away with many ideas to explore.

One perspective the talk gave to me is related to a sentence from James:
We should replace XML formatted messages by RDF ones.
Out of context, it does mean silly: why would replace messages with already a large payload by ones even bigger? Especially when most of Web 2.0 tries to rely on JSON as much as possible...

Let me present an example and you will probably see which benefits I envision in my expertise area (which focuses on Web 2.0 applications, but which covers all types of light clients).
1. <notification uri="uri://" date="20080721T164300Z">
2.   <priority>...</priority>
3.   <emitter name="Automatic Alert" uri="uri://" />
4.   <content type="text">
5.     Unexpected power outage in 5 minutes.
6.     Call Jack: 123.456.7890 #0923
7.   </content>
8. </notification>
Over the week-end, I receive such a message on smart phone and I call Jack right away. But due to the urgency of the situation, Jack moved somewhere else and no one picks up the phone. I do not have this “Jack” in my cellular phone address book and the company front desk is closed: I am stuck!

It might be less problematic if the message contains a record with an equivalent of Jack vCard [5], so I will be able to find his cellular phone number to reach him. If he does not reply (he does not hear the cellular phone ringing because of the noise of the electrical generators he has just started, for example), I am stuck again...

A corresponding notification literally translated in a RDF graph will rely on the following relations:
1. {uri://; date; 20080721T164300Z}
2. {uri://; priority; ...}
3. {uri://; emitter; uri://}
4. {uri://; name; "Automatic Alert"}
5. {uri://; content; uri://}
6. {uri://; type; "text"}
7. {uri://; value; "Unexpected power outage in 5 minutes\nCall Jack: 123 456 7890 #0923"}
This set of triplets does not bring much value than its XML counterpart. But it is not RDF-friendly neither... The last triplet (line 7) contains too much information, so let rewrite it:
1. {uri://; _1; "Unexpected power outage in 5 minutes."}
2. {uri://; _2; "Call"}
3. {uri://; _3; uri://}
4. {uri://; _4; ":"}
5. {uri://; _5; uri://}
Now, it is visible that Jack is the name of the staff number with the internal identifier 456. Jack should be also called in room or cube with the internal identifier 16.
If the corporate directory uses a RDF representation, if it supports SPARQL to process lookups, I have now many possibilities to act:
  • I can query information about Jack (uri:// his cellular phone number, his desk phone, his role, etc.
  • I can get information about the room in order to go there (if I am the building), or to call someone next to it.
  • I can also look for someone having a direct relation with Jack (e.g. his manager) or having the same profile (a teammate possibly trying to fix the crisis too).
Note that these benefits come naturally, without requiring notification schema extensions (like the proposed one to include vCards of human actors).

For sure, the payload of such a representation is bigger than traditional ones. In case of sending such notifications to mobile devices and equivalent query results, the limited bandwidth can become the bottleneck. This problem can be worked around by having hand held devices owners synchronizing them quite often (disk space is cheaper than bandwidth, it is also much faster). This alternative requires the implementation of efficient RDF engine (parser, query, inference).
A+, Dom

1 comment:

  1. Dear DOM,
    I believe that your example is a good one. For the question of bandwidth, a simpler N3 notation could be used. Moreover, the SPARQL protocol standard defines and HTTP based API, hence the cost of sending queries to a central SPARQL engine which aggregates all the company RDF information would be small; it would not be necessary to have any local data, only a HTTP connection to the web.