David S. Read

In an earlier blog entry I discussed the potential reduction in refactoring effort if our data is represented as RDF triples rather than relational structures.  As a way to give myself easy access to RDF data and to work more with semantic web tool features I have created a program to export relational data to RDF.

The program is really a proof-of-concept.  It takes a SQL query and converts the resulting rows into assertions of triples.  The approach is simple: given a SQL statement and a chosen primary key column (PK) to represent the instance for the exported data, assert triples with the primary key column value as the subject, the column names as the predicates and the non-PK column values as the objects.

Here is a brief sample taken from the documentation accompanying the code.

• Given a table named people with the following columns and rows:

       id    name    age
       --    ----    ---
       1     Fred    20
       2     Martha  25

• And a query of:  select id, name, age from people
• And the primary key column set to: id
• Then the asserted triples (shown using Turtle and skipping prefixes) will be:

       dsr:PK_1
          a       owl:Thing , dsr:RdbData ;
          rdfs:label "1" ;
          dsr:name "Fred" ;
          dsr:age "20" .

       dsr:PK_2
          a       owl:Thing , dsr:RdbData ;
          rdfs:label "2" ;
          dsr:name "Martha" ;
          dsr:age "25" .

You can see that the approach represents a quick way to convert the data.

(more…)

I have create my first slightly interesting, to me anyway, program that uses some semantic web technology.  Of course I’ll look back on this in a year and cringe, but for now it represents my understanding of a small set of features from Jena and Pellet.

The basis for the program is an example program that is described in Hebler, Fischer et al’s book “Semantic Web Programming” (ISBN: 047041801X).  The intent of the program is to load an ontology into three models, each running a different level of reasoner (RDF, RDFS and OWL) and output the resulting assertions (triples).

I made a couple of changes to the book’s sample’s approach.  First I allow any supported input file format to be automatically loaded (you don’t have to tell the program what format is being used).  Second, I report the actual differences between the models rather than just showing all the resulting triples.

As I worked on the code, which is currently housed in one uber-class (that’ll have to be refactored!), I realized that there will be lots of reusable “plumbing” code that comes with this type of work.  Setting up models with various reasoners, loading ontologies, reporting triples, interfacing to triple stores, and so on will become nuisance code to write.

Libraries like Jena help, but they abstract at a low level.  I want a semantic workbench that makes playing with the various libraries and frameworks easy.  To that end I’ve created a Sourceforge project called “Semantic Workbench“.

I intend for the Semantic Workbench to provide a GUI environment for manipulating semantic web technologies. Developers and power users would be able to use such a tool to test ontologies, try various reasoners and validate queries.  Developers could use the workbench’s source code to understand how to utilize frameworks like Jena or reasoner APIs like that of Pellet.

I invite other interested people to join the Sourceforge project. The project’s URL is: http://semanticwb.sourceforge.net/

On the data side, in order to have a rich semantic test data set to utilize, I’ve started an ontology that I hope to grow into an interesting example.  I’m using the insurance industry as its basis.  The rules around insurance and the variety of concepts should provide a rich set of classes, attributes and relationships for modeling.  My first version of this example ontology is included with the sample program.

Finally, I’ve added a semantic web section to my website where I’ll maintain links to useful information I find as well as sample code or files that I think might be of interest to other developers.  I’ve placed the sample program and ontology described earlier in this post on that page along with links to a variety of resources.

My site’s semantic web page’s URL is: http://monead.com/semantic/
The URL for the page describing the sample program is: http://monead.com/semantic/proj_diffinferencing.html

Encapsulation, one of Object Orientation’s (OO) “Big Three” (or four if you include composition), is the concept most often forgotten when I ask an interview candidate to define the key tenants of OO.  Giving the benefit of the doubt, perhaps it is considered “obvious” and hence not necessarily related to OO design in the person’s mind.  Once I bring it up though, there is usually agreement that it is an important aspect to achieving significant value from OO design.

Classically, encapsulation, also called information hiding, “serves to separate the contractual interface of an abstraction and its implementation.”¹ The idea is that the user of the functionality only knows about the public interface (contractual interface) and has no knowledge, nor any ability to tie itself, to the implementation.  The implementation includes both data representation and, effectively, algorithm.

Many times I’ll get an alternate definition; essentially the respondent will define encapsulation as, “as an approach which allows an object’s behavior to be called without the caller having knowledge of how the behavior is implemented.”  This seems very close to the classical definition but misses the key point of “contractual interface.”

I could argue that when any method is called the caller doesn’t have knowledge of how the method is implemented; it just gets a value back.  The missing aspect, the key aspect, is the constraint regarding which methods the caller may call, e.g. the public interface.

What started me on this topic was a recent conversation with a peer regarding read-only objects.  Before I get into specifics, let me baseline the traditional encapsulation approach in a typical object.

(more…)

During the past several months I’ve had an interesting experience working with Brainbench.  As you may know, Brainbench (a part of Previsor) offers assessment tests and certifications across a wide range of subjects.  They cover many technical and non-technical areas.  I have taken Brainbench exams myself and I have seen them used as a component within a hiring process.  However, I did not understand how these exams were created.

That mystery ended for me late last year when I received an email looking for technologists to assist in validating a new exam that Brainbench was creating to cover Spring version 2.5.  Being curious about the test creation process I applied for the advertised validator role.  I was pleasantly surprised when they contacted me with an offer for the role of test author instead.

I will not delve into Brainbench’s specific exam creation approach since I assume it is proprietary and want to be sure I respect their intellectual property.  What I found was a very well-planned and thorough process.  Having a background in education and a strong interest in teaching and mentoring, I know the challenge of creating a meaningful assessment.  In the case of their approach, they focus on an accurate and well-considered exam.

I believe that I am quite knowledgeable regarding Spring.  I have used many of its features for work and personal projects.  The philosophies supported by the product (encouraged, not prescribed) address many areas of coding that help reduce clutter, decouple implementations, and simplify testing.  As a true fan of Spring’s feature set, I found it challenging to decide which aspects were most important when assessing an individual’s knowledge of the overall framework. (more…)

Full Disclosure: The title of this post quotes a phrase I have heard countless times from Java programmers.  The statement itself is misleading.  The Vector class cannot guarantee thread safety for an application.  Let me tell you why…

When considering thread safety we really have to consider the context under which we need thread-safe operations.  In the Java world we tend to focus on synchronizing methods as a quick way to achieve a thread-safe design and the Vector class is the poster child for this approach.  In fact I often hear that using a Vector is better than ArrayList when dealing with multi-threaded applications.

By synchronizing its methods a Vector does protect itself from unpredictable changes to its internal state.  In other words, the Vector is guaranteed to be internally consistent.  For instance, if two threads attempt to do an insert at position 3 at the same time, one will be inserted first and the other will then be inserted (moving the previously inserted value to position 4 in this case).  The synchronized methods prevented any odd collision where one of the values might be lost.

However this internal protection does nothing to protect our external view of the Vector.  In the face of multiple threads updating the Vector there is no advantage of the Vector over an unsynchronized class like ArrayList.  Why?  It comes down to what actually needs to be locked in support of creating an atomic operation.

The synchronized methods in Vector imply that the atomic operation is the individual Vector method.  However, in a multithreaded application the definition of an atomic operation probably has a larger scope.  For instance, if the Vector is helping to maintain a collection of calculation results, the atomic operation might be the entire cycle of reading the value from the Vector, calculating a new value and replacing the value in the Vector.

In order to understand how this would work we need to understand a mutex.  The term mutex comes from “Mutual Exclusion” and signifies that some portion of our code needs mutually exclusive access to some object(s).  In the case of synchronized (non-static) methods the mutex is the object itself.  Therefore, all those synchronized methods in the Vector class require that they have an exclusive lock on the Vector instance. 

(more…)

I was recently working on a Java program whose only interactions were through web services. The application accepted web service requests and, as part of its processing, made other web service requests to other services. I leveraged a couple of frameworks to simplify the web service interactions, namely Spring and Castor. Spring-WS provided the web service endpoint support and Castor did all my marshalling and unmarshalling.

At this point you may be asking what this has to do with Thread Safety. I am glad you asked. It could be that my title is misleading, but I believe the next paragraph will help resolve any apparent disconnect.

As part of integrating the marshalling and unmarshalling process involved in the web service, I needed to create JavaBeans™, which provide the objects housing the program’s data. However, since a framework was handling the marshalling and unmarshalling process, I never used the new keyword. Nor did I call the bean’s accessors or mutators directly when reading or writing the XML. Instead, the framework decided the order of get and set calls, and more to my point, I wondered whether the framework was free to multithread the interactions.

The reason for my concern was that one of my beans had a dependency between two properties. If one was set to a certain value, the other was impacted. The framework controlled the order of calls, so I had to deal with either being set first. Handling order was not a big issue, but what if their mutators were called simultaneously?

This led me to look more closely at the JavaBean™ specification. I was interested in whether it mentions anything about multi-threaded access. If it stated that beans should not expect multi-threaded access by default, then I was in good shape. Otherwise, the framework might have me at a disadvantage.

(more…)