interface cobalt

A number of weeks ago, I began work on the software part of my MSc project. That software recently became feature complete.

The software is a gateway that takes what’s on the current Web and lifts it to the Semantic Web. It does that by means of several mechanisms: protocol handlers (e.g., for HTTP), content type handlers (lifting from various content types to RDF, and lowering from RDF to other content types), XML namespace handlers (lifting of XML documents based on document namespaces), and adaptations that for, e.g., certain REST services or URN namespaces can override the handlers and otherwise modify the requests and responses.

A major part of these adaptations is SAWADL, which is SAWSDL applied to WADL. As far as I know, there has been no previous specification of a format that extends WADL with semantic annotations, so I intend to publish such a specification. (Similar formats have certainly been thought of before, however.) The idea is that content and services on the existing Web can, in such a way, be given semantics (according to Semantic Web standards such as RDF) and also be made more RESTful.

My hope is that this type of software will both simplify usage of services on the Web and make them more powerful, particularly with regards to interoperability. Oh, and I should mention that the gateway itself operates according to REST principles and, for any URI given to it, acts as I believe should be best practice for a RESTful and Semantic Web. E.g., if asked for a HTML document (in the HTTP Accept header), that’s what it will return, and if asked for RDF XML or JSON-format data, it will give you that, for any Web resource.

Ok, I’ve finished my rather late espresso now and the shop’s closing. Anyway, I believe I’ll do some more posting about the software and the ideas behind it. Hopefully, I’ll be able to post the software itself (and its source) on the Web.

For those of you who use the excellent Url Rewrite Filter, a Java Web Filter which allows you to rewrite URLs before they get to your code, here are a couple of more-or-less useful rewrite rules that I’ve created.

The first rule redirects access made through a non-preferred domain or subdomain name to the preferred one. For example, if you’re using the example.com domain name for your website, you might want to redirect http://example.com/page.jsp to http://www.example.com/page.jsp.

<rule>
 <name>Domain Name Check</name>
 <condition name="host"
  operator="notequal">www.example.com</condition>
 <!–
     Needed if using a version prior to 2.0-alpha:
     <condition name=”host”
      operator=”notequal”>www.example.com</condition>
 –>
 <from>(.*)</from>
 <to type=”redirect”>http://www.example.com/context$1</to>
</rule>

Obviously, just replace www.example.com with the domain name that you prefer, and context with the context which your webapp is deployed at, or if using the root context, remove /context altogether.

I should mention that I didn’t write the same condition twice by mistake. There seems to be a bug in UrlRewriteFilter (version 1.2) which causes such conditions to be ignored unless written twice. If somebody hasn’t filed a report on that one already, I guess I better do it. Update: Paul Tuckey, the creator of Url Rewrite Filter, emailed me to let me know that this problem has been fixed in version 2.0-alpha.

The second rule blocks access to JSPs (or anything you want) that you don’t want to be accessible by anyone, and shows the 403: Forbidden error page which you’ve configured in your web.xml file.

<rule>
 <name>JSP block</name>
 <from>^/jsp/.*$</from>
 <set type="request" name="status_code">403</set>
 <to>/jsp/sendError.jsp</to>
</rule>

Where /jsp/sendError.jsp contains the following:

<%
 response.sendError(Integer.parseInt(
  (String)request.getAttribute("status_code")));
%>

Note that you could use any status code you want; if you want to give the user a 404: Not Found error, just write 404 instead of 403 in the rule configuration.

Now, what’s the best RegExp to find out whether a given user-agent is from a cell phone? Hmm.

The Java category (feed) of this weblog is now aggregated on java.blogs. I thought it would be a good idea to add it there, and the referrer statistics seem to prove me right.

Since I added the feed of the Java category, entries like this one won’t show up on java.blogs. After all, I’ve been posting quite a lot of entries unrelated to Java, so I thought that would be the best way to do it.

Anyhow, all of you who’ve come here from java.blogs, and all other new readers as well, welcome!