[vsr]The last few evenings I spend writing an extension concept for the WebComposition/DGS approach. Initially, I was looking for a semantic description for the RESTful interface of the DGS. There are plenty approaches and a lot of research is going on for extending the WSDL interfaces with semantics. OWL-S and WSMO might be the most important examples within this field. However, it appears to be a bit more tricky for REST-driven approaches. For the DGS, I decided to try the SA-REST approach of the Kno.e.sis Services Science Lab of the Wright State University, Ohio.

However, I did not want to make this as a internal component of the DGS as is a research project, and no recommendation or standard is out there yet. So I came along with the extension concept of the DGS that allows dynamically loading of additional extensions in addition to the core components of the DGS.

The IExtension interface provides hotspots were own code can be executed right before and after one of the CRUD (Create, Read, Update, Delete) events.

          
  1: namespace WebComposition.Dgs.Extension 
          
  2: {

          
  3:     publicinterface IExtension 
          
  4:     {

          
  5:         bool CreateStartUp(ref ExecutionContext
context); 
          
  6:         bool CreateTearDown(ref ExecutionContext
context); 
          
  7:         bool ReadStartUp(ref ExecutionContext
context); 
          
  8:         //...
          
  9:     }

          
 10: }
        

The ExecutionContext contains the request URI, the corresponding data adapter and (if already available)  the current content to be returned with the response.

The extension can modify or create the content to be returned. In this case the return value must be set to false. Returning this dirty flag the DGS knows that the extension provided a new content to be returned. Any further internal functionality by the DGS is thus skipped and the newly provided content from the extension is returned.

To keep the WebComposition/DGS approach as flexible as possible, extensions can be deployed at runtime. The DGS is instructed to use extension by specifying them within the web.config file.

          
  1: <webComposition>
          
  2:     <dataGridService>
          
  3:     <extensions>
          
  4:         <extensiontype="WebComposition.Dgs.Extensions.SaRest.SaRestHandler, 

          
  5:                    WebComposition.Dgs.Extensions.SaRest, 

          
  6:                    Version=1.0.0.0, 

          
  7:                    Culture=neutral, 

          
  8:                    PublicKeyToken=null" />
          
  9:       </extensions>
          
 10:       ...

          
 11:     </dataGridService>
          
 12: </webComposition>
        

Based in this extension mechanism I created my very first extension to provide SA-REST support. If you have a closer look to SA-REST you might realize a drawback of the approach (one that is directly related to the REST principles). When using RDFa or any other microformat in HTML/XHTML the description of the service is rather static. The DGS on the other hand provides a highly flexible solution. Here, the full power of the DGS turn up. Analyzing the SA-REST annotation you will realize that you have RDF triples, e.g. metadata. This metadata can be stored within the DGS of course.

If we have a closer look on this metadata we can add this metadata by performing an updated on your service's meta URI. In my case it is http://localhost/datagridservice/DataGridService/meta.  Below we use some RDF based on the originally SA-REST example.

          
  1: <rdf:Descriptionrdf:about="http://localhost/datagridservice/DataGridService">
          
  2:     <SAREST:inputrdf:resource="http://lsdis.cs.uga.edu/ont.owl#Location_Query"/>
          
  3:     <SAREST:outputrdf:resource="http://lsdis.cs.uga.edu/ont.owl#Location"/>
          
  4:     <SAREST:action>HTTP
GET</SAREST:action>
          
  5:     <SAREST:liftingrdf:resource="http://www.restful.ws/lifting.xsl"/>
          
  6:     <SAREST:loweringrdf:resource="http://www.restful.ws/lowering.xsl"/>
          
  7:     <SAREST:operationrdf:resource="http://lsdis.cs.uga.edu/ont.owl#Location_Search"/>
          
  8: </rdf:Description>
        

The SA-REST extension now extends the URI scope of the DGS - which is actually a very cool feature. Once deployed, the /meta scope is extended with /meta/sarest. If you now perform a GET request to http://localhost/datagridservice/DataGridService/meta/sarest. The extension will return the corresponding SA-REST metadata we used above.

To round up this exercise I've also created a set of XSL transformations that create XHTML to be used within any Web page. E.g. the SA-REST annotation mixed with the content, again based on the original SA-REST example, would look like below. Keep in mind, the XHTML snippet you see here was dynamically created by the DGS itself using a transformation.

          
  1: <pabout="http://localhost/datagridservice/DataGridService"xmlns="http://www.w3.org/1999/xhtml"xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"xmlns:sarest="http://lsdis.cs.uga.edu/SAREST#">
          
  2:     The logical input of this service is an

          
  3:     <spanproperty="sarest:input">http://lsdis.cs.uga.edu/ont.owl#Location_Query</span>
          
  4:     object. The logical output of this service is a list of

          
  5:     <spanproperty="sarest:output">http://lsdis.cs.uga.edu/ont.owl#Location</span>
          
  6:     objects. This service should be invoked using an

          
  7:     <spanproperty="sarest:action">HTTP
GET</span>
          
  8:     request.

          
  9:     <metaproperty="sarest:lifting"content="http://www.restful.ws/lifting.xsl"/>
          
 10:     <metaproperty="sarest:lowering"content="http://www.restful.ws/lowering.xsl"/>
          
 11:     <metaproperty="sarest:operation"content="http://lsdis.cs.uga.edu/ont.owl#Location_Search"/>
          
 12: </p>
        

The extension concept allows to add new custom components and to customize the DGS even more while the SA-REST extension provides a very first capability to describe the DGS' RESTful interface in a semantic way.

I am going to do a second proof of concept using another approach describing RESTful services soon to show the flexibility of the extension concept.

[rdf]Today, I spent some minutes to perform an experiment on linked data. The D2R server at L3S - University of Hannover publishes a weekly update version of the DBLP bibliography. The URIs from the Hannover server can thus be used to to set RDF links to DBLP data.

The FOAF profile is quite meaningless when used in a stand-alone to the machine-readable Web, similar to HTML pages without any links. With additional links to other machine-readable Web - and there are quite a lot resources available right now on the Web but you still have to find them. I was told a very visual metaphor where you could understand the Semantic Web as it is today as a country with hundreds or thousands of train stations but no tracks between those stations. As long as there are no tracks build, the train stations do not provide any added value. Similar it is to the Semantic Web. Unfortunately, establishing the links between the resources is still a very manual and time intensive job that must be accomplished by the human user.

Once linked, it becomes interesting when using the appropriate tools to browse these information. The best (even when experimental) tools therefore are the following Semantic Browsers:

• Tabulator Project
• Disco Hyperdata Browser
• OpenLink RDF Browser

To link myself to the DBLP database URI, I simply have to add an owl:sameAs tag to my FOAF profile. This allows to follow Semantic Web Browsers the links to the DBLP database. The different kinds of links you can add to your profile can are explained in a tutorial at FU Berlin.

As adding these links is still a manual process, I now think of creating a small component that will update publications in my FOAF file in the future based on a XML input file. That will allow me to semi-automate the process of updating the FOAF file. Some good reasons are

• It's easier to write down pure XML rather than RDF.
• I can reuse the XML on other places, such as the publication list on my Web site
• The links to the corresponding DBLP entries will be searched automatically.

Comments are warmly welcomed.

It's official now: From the next term on, Chemnitz University of Technology offers a Master of Data and Web Engineering. Interested in it? Get the English flyer here[pdf]. There is also a verbose German description available here [pdf]. Why this is cool? Because you can study and learn with one of the founders of the Web Engineering community. If you are interested in this topic read the first paper in the first issue of the Journal of Web Engineering from 2002 [pdf]. Definitely cool.

With the last update on the WebComposition/DGS, we now provide RSS feeds for CRUD events. Therefore, the Meta-URI /meta is extended by the additional path segments /meta/crud, /meta/crud and /meta/crud/rss. The Meta-URI /meta/crud can be extended to /meta/crud/create,  /meta/crud/read, /meta/crud/update and /meta/crud/delete. Each URI points to a certain set of events. The event URIs in form of http://www.foo.bar/meta/crud/abab1c07-9262-4e6a-9f52-3dc497ef92f1 point directly to the RDF of the corresponding event.

Following this HTTP-URI will lead directly to corresponding description of the events as seen below. Therefore, we take care of our carefully chosen URI concept within the WebComposition/DGS approach.

          <
          rdf:RDF
          
          
          xmlns:rdf
          ="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:meta="http://www.webcomposition.net/2008/02/dgs/meta/" xmlns:ns="http://purl.org/dc/elements/1.1/" xmlns:crud="http://www.webcomposition.net/2008/02/dgs/crud#">
<rdf:Descriptionrdf:about="http://www.foo.bar/DataGridService">
<meta:event>
<rdf:Descriptionrdf:about="http://www.foo.bar/DataGridService/meta/crud/abab1c07-9262-4e6a-9f52-3dc497ef92f1">
<ns:date>2008-05-15T19:20:13.7+02:00</ns:date>
<ns:creator />
<crud:readrdf:resource="http://www.foo.bar/DataGridService/foobar" />
</rdf:Description>
</meta:event>
</rdf:Description>
</rdf:RDF>

A more visual depiction of the event can looks like below. Following the RDF data you are pointed to the resource that was affected by the event.

[svn]After some discussion about the WebComposition/DGS configuration this week, we changed the usage of schema validation with the Web.config file. The validation scope is now not bound anymore to data adapters directly. Rather we introduced a default validation defined in the Web.config such as

           <
          webComposition
          >
<
          dataGridService
          >
<
          defaultValidation
          
          
          scope
          ="None"/>

... 

Valid values are 'None', 'List' and 'Element'.This schema scope represents the default schema validation scope whenever an information store is created and data is added. If set to 'None' no validation is performed at all. Using 'Element' the added XML is validated against the schema (a-priori validation) before the element is added to the information store while  the usage of 'List' causes the data to be validated against the schema after being added to the information store (a posteriori validation).

The settings can be easily overwritten by using RDF meta data e.g. when using the N3 filter on a information store http://www.foo.bar/myStore:

<http://www.foo.bar/myStore>
http://www.webcomposition.net/2008/02/dgs/meta/validation
"Element".

That way, the default value can be always adapted to the specific need for a single information store.

[svn] Another major forward integration of the student branch of the WebComposition/DGS: With revision 1228, CRUD events are supported on service level. I.e. each create, read, update or delete operation on the service (or it's lists) is stored within the meta data of the service. The vocabulary supported for the CRUD events is therefore defined as follows:

• http://www.webcomposition.net/2008/02/dgs/crud#create for create events.
• http://www.webcomposition.net/2008/02/dgs/crud#read for read events.
• http://www.webcomposition.net/2008/02/dgs/crud#update for update events.
• http://www.webcomposition.net/2008/02/dgs/crud#delete for delete events.

Exemplary meta data fore creating, updating, reading from and deleting an information store on a service running at 'http://localhost/dgs' would look like

<? xml version ="1.0"?>
<rdf:RDFxmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
        xmlns:dc="http://purl.org/dc/elements/1.1/"
        xmlns:dm="http://www.webcomposition.net/2008/02/dgs/meta/"
        xmlns:crud="http://www.webcomposition.net/2008/02/dgs/crud">
    <rdf:Descriptionrdf:about="http://localhost/dgs">
        <crud:createrdf:resource="http://localhost/dgs/store" />
        <crud:updaterdf:resource="http://localhost/dgs/store" />
        <crud:readrdf:resource="http://localhost/dgs/store" />
        <crud:deleterdf:resource="http://localhost/dgs/store" />
    </rdf:Description>
    ...
</rdf:RDF>

The CRUD event meta data can be obtained as by the /meta URL of the corresponding service.

[svn]Today, I got the first feedback by some of the students about the WebComposition/DGS. Beside the typical start-with-a-new-technology issues considering Visual Studio 2008, ASP.NET and WCF, it looks like the first steps are done successfully. Based on the feedback I received during the day I did several fixes beside the regular enhancements. This evening, I performed a forward integration to incorporate the latest fixes. If you are using the Student Branch, please make sure to  update to revision 1211. 

Changes for today include:

• updated XML documentation of WebComposition.Dgs.Content namespace
• added notes about AppData/Service folder to DemoWeb
• added tests for meta data on service and information store level
• fixed '400 Bad Request' when no write access to AppData folder is given
• fixed SemWeb.dll reference in Content project, now expected to be in /External

[svn]I spend the weekend it setting up the VSR's distributed version control system. From this morning on, the student branch is fully sync'ed and ready to be compiled. Make sure to read the readme.txt in the root directory of the project and copy the SemWeb.dll into your External directory before the first compile run.

[svn]In preparation for our first LAKS meeting, I did a major forward integration of the WebComposition/DGS trunk into our student branch. The documentation in the DemoWeb project is now completely updated and available in the student branch. Several minor updates will follow in the next few days. A brief description how to create a private branch can be found here.

[clock]The first Learn And Knowledge Sharing (LAKS) Meeting at the Distributed and Self-organizing Systems Group will be held at Wednesday, the 30th April 2008 in Room B203. The time is 13:00 - 16:00 . The following appointments will be every Thursday, 13:00 - 16:00 in Room B203.

While dealing a lot with RDF and Notation3 (N3),  I was looking for a way to check my N3 expressions. At W3C's site you can find a N3 validator that allows you to validate your statements against Notation3 grammar.

I recently got accepted a paper at the REALWSN'08 workshop that is in conjunction with ACM EuroSys 2008 in Glasgow, Scotland. The paper deals with a project performed by Microsoft Research Cambridge using a wireless sensor network deployed on Skomer island in the UK, monitoring the Manx Shearwater seabird.

Following the VSR group's main idea, I spend some time in updating my personal FOAF file. The best way to understand Semantic Web is practicing it. The resource you know the most about is your person. So, FOAF provides you some neat opportunities to get in touch with W3C's RDF technology.