How to get a list of Extensions in WebComposition/DGS

If you are not sure if a DGS instance provides a certain extension, just have a look at the metadata of the service, e.g. You will find the all the available extensions with the predicate″02/dgs/meta/extension (we say “has extension”). In the example below we find the SA-REST extension I have introduced yesterday.

<rdf:RDF xmlns:rdf=""
  <rdf:Description rdf:about="">
    <!-- ... -->
    <!-- ... -->

WebComposition/DGS Extensions and SA-REST Support

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.

<rdf:Description rdf:about="http://localhost/datagridservice/DataGridService">
    <SAREST:input rdf:resource="" />
    <SAREST:output rdf:resource="" />
    <SAREST:action>HTTP GET</SAREST:action>
    <SAREST:lifting rdf:resource="" />
    <SAREST:lowering rdf:resource="" />
    <SAREST:operation rdf:resource="" />

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.

namespace WebComposition.Dgs.Extension
    public interface IExtension
        bool CreateStartUp(ref ExecutionContext context);
        bool CreateTearDown(ref ExecutionContext context);
        bool ReadStartUp(ref ExecutionContext context);

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.

        <extension type="WebComposition.Dgs.Extensions.SaRest.SaRestHandler,
                   PublicKeyToken=null" />

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.

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.

<p about="http://localhost/datagridservice/DataGridService" xmlns="" xmlns:rdf="" xmlns:sarest="">
    The logical input of this service is an
    <span property="sarest:input"></span>
    object. The logical output of this service is a list of
    <span property="sarest:output"></span>
    objects. This service should be invoked using an
    <span property="sarest:action">HTTP GET</span>
    <meta property="sarest:lifting" content="" />
    <meta property="sarest:lowering" content="" />
    <meta property="sarest:operation" content="" />

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.

DBLP Linked Data Experiment

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:

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.

RSS for CRUD Events

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 point directly to the RDF of the corresponding event.

CRUD Event RSS Feed

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=""
    <rdf:Description rdf:about="">
            <rdf:Description rdf:about="">
                <ns:creator />
                <crud:read rdf:resource="" />

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.

CRUD Events


&lt;rdf:RDF xmlns:rdf=&quot;;
&lt;rdf:Description rdf:about=&quot;;&gt;
&lt;rdf:Description rdf:about=&quot;;&gt;
&lt;ns:creator /&gt;
&lt;crud:read rdf:resource=&quot;; /&gt;



By the W3C the term ontology is defined as following:

Ontology is a term borrowed from philosophy that refers to the science of describing the kinds of entities in the world and how they are related.

If you start to dig a bit you’ll realize a couple disillusioning facts:

The Web Ontology Language is there for quite a while. But there is no significant impact on Web Engineering, yet. RDF and thus OWL is not designed to be read by humans. But OWL is not supported out of the box, e.g. in the .NET framework. To design ontologies you would need an editor, but all you can find is Protégé. Protégé is not bad at all, but the Protégé OWL documentation roughly four years old. The only elaborate documentation on OWL is the W3C recommendation.