Semantic Versioning

In my current team (actually the whole company) we end up within the dependency hell day by day. Not only that many teams just don’t do any versioning, if they do there are no clear rules how they should do.

Semantik Versioning specification provides a great introduction of how and when to use (semantic) versioning. Definitely worth a read.

In the world of software management there exists a dreaded place called “dependency hell.” The bigger your system grows and the more packages you integrate into your software, the more likely you are to find yourself, one day, in this pit of despair.

In systems with many dependencies, releasing new package versions can quickly become a nightmare. If the dependency specifications are too tight, you are in danger of version lock (the inability to upgrade a package without having to release new versions of every dependent package). If dependencies are specified too loosely, you will inevitably be bitten by version promiscuity (assuming compatibility with more future versions than is reasonable). Dependency hell is where you are when version lock and/or version promiscuity prevent you from easily and safely moving your project forward.


IEEE Data Breach

A few days ago, Radu Drăgușin discovered a data leak at the IEEE servers, enabling him to download about 100.000 plain text keywords (probably mine as well).

On the one hand it shows how critical it is to consider the security off your system, nevertheless if you are a small company or a worldwide organization such as the IEEE. On the other hand it showed that even large organizations you never thought of this might face such fatal security leaks.

However, Radu went ahead and (a) decided not to share the information he gained through this security leak with public (big kudos for this decision), (b) to prepare various statistics on based on the information (which are indeed interesting without revealing traceable information about individuals) and (c) to inform IEEE about the leak (also kudos for this). As a result you can say, he was quite responsible with the data he received and at least e followed some of the principles, provided by the IEEE Computer Society Code of Ethics.

One result of his analysis is the fact, that about almost 300 users are using the password 123456, reminding me Mel Brooks epic Star Wars parody Spaceballs, Dark Helmet saying

“So the combination is… one, two, three, four, five? That’s the stupidest combination I’ve ever heard in my life! That’s the kind of thing an idiot would have on his luggage!”

As a result, I went straight to my IEEE account and changed the password. Luckily, it was a password not used for any other site beside the IEEE. Said that, if you have an IEEE account, it probably is a good thing to go there directly changing yours as well if not already done.

Most used IEEE passwords

And Radu, whenever you ever read this post, if have the chance please have a look into the log files and let me know if the user aheil is listed there as well.

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.

WebComposition/DGS Core Architecture

Ok, how would you describe the core architecture of your current project? Inspired by Ralf’s idea, I really thought about the WebComposition/DGS architecture. What are the e core concepts and the key ideas of it? If everything has to fit on a napkin, you really have to restrict yourself in drawing different components. The interactive NapkinNotebook thus cam in very handy. Let’s look at the first try of the architecture sketch?

WebComposition/DGS Core Architecture

What are the core components we find in the WebComposition/DGS? Well, there is the Data Grid Service (DGS) as central entity? What else? Some storage solution for data and some other storage solution for metadata. Ok, here we have to think the first time? Two of them? Definitely yes. Metadata might be saved a completely different way than the data itself. You don’t think so? Let’s see, think about our images as digital photos and the metadata created from the EXIF data extracted from the imaged. The EXIF data is stored as RDF in some triple store, the images are stored on the file system. Consequently, we need two storage solutions.

OK, next component on the diagram: Users; do the interact directly with the DGS? No, usually the use a Web-based application. The user also might be another application or a service – but that’s no information to be on this sketch. The important thing is: there is usually only interaction through some other component – usually a Web-based application.
After some feedback from Ralf, I’ve updated my sketch using another software cell for the Web application. Makes much more sense though, what do you think?


There is an upcoming book I am looking forward to: O’Reilly’s RESTful .NET by Jon Flanders.

That’s what the cover text says so far:

“RESTful .NET is the first book that teaches Windows developers to build RESTful web services using the latest Microsoft tools. Written by WFC expert Jon Flanders, this hands-on tutorial demonstrates how you can use WCF and other components of the .NET 3.5 Framework to build, deploy and use REST-based web services in a variety of application scenarios. No prior knowledge of REST or WCF is required to get started.”

I am thinking about the REST concept now for a while and I am really interested in the way Jon is going to address some of the issues such as secure REST endpoints. He will also address the ADO.NET Data Services which follow the REST principles quite well. I am not to optimistic right now about it, since REST is not as easy as it is commonly thought.

The book is scheduled for October and so I just added it to my wish list, not to forget about it.

Master of Data and Web Engineering

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. There is also a verbose German description available. 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. Definitely a step forward for this research area.

Master of Data and Web Engineering

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;