The Semantic Web has been a strong interest of mine over the last two years. When I came across RDF and OWL through a research project at IST back in 2008, a Web Standard no less, I'd somehow been completely oblivious to its existence.

If you've never heard of the Semantic Web, here's a quick intro video. I'll wait here.

Everybody back? Okay! The concepts behind OWL seemed to solve a few thorny design issues I'd come across in a decade of building relational databases-backed Web 1.0 apps, and do so in a really elegant way. Working with OWL fuses aspects of relational database modeling, information architecture, and object oriented design into a new set of technologies and techniques.

As I started talking to members of the developer community at Penn State about the Semantic Web, I got a lot of blank stares and misunderstandings ("Isn't that just XML?"). And yet, every graduate student in IST was exposed to ontologies and semantic modelling as a routine part of the curriculum. The research community had been working with ontologies for years. Clearly there was a large academic-practitioner gap here to be bridged.

So as I've done many times in the past with a new technology or concept, I started talking about the Semantic Web at user group meetings and conferences, and looking for ways to apply these technologies in low-risk venues.

Tonight is the latest in this series of speaking engagements, and possibly the most challenging thus far. I'll be presenting my talk "An Argument For Semantics" at the Portland Java User Group. I've been really impressed by the quality of home grown presenters at PJUG since I started attending. My talk will be very different - less code, more conceptual - than usual PJUG speakers, but I'm hoping the technical experience in the room can generate a good discussion on how and when it makes sense to employ Semantic Web technologies in real world applications.

If you regularly run your browser with JavaScript support disabled like I do, you'll occasionally run into a Web site that completely fails to operate, especially among so-called Web 2.0 sites.

I don't know if you've ever noticed, but Twitter.com is not the most accessible site on the Web. I find that somewhat odd, given the relative simplicity of the user interface. This has improved a bit in the 18 months or so that I've been using the service, but I wouldn't say it's perfect yet. At least the site functionality gracefully degrades when you don't have JavaScript.

Enter Dennis Embree. Seeing a need, or at least an opportunity, he created a more accessible Web-based Twitter interface: AccessibleTwitter.com

The site contains a short list of some of the things the developers fixed:

• All links are keyboard accessible.
• Simple, consistent layout and navigation.
• Works with or without JavaScript.
• Large default text size and high color contrast.
• Looks great in high or low resolution.
• Forms are marked up for optimal accessibility.
• Code is semantic, light, and adheres to best practices in Web Standards.

I wonder if there is a niche here for accessibility-aware Web developers: find Web 2.0 sites that brush off demands for accessibility affordances and wrap them in a "cloak of accessibility" spun from their own APIs.

I think this is a really interesting idea. I wonder what other sites could benefit from such a technique?

We're in the midst of building an interesting Rich Internet Application for educational assessment using Flex. We've had a lot of success with our process thus far, so I thought it would be helpful to document it as a means of discussing it and maybe improving it for our next project.

One of the great aspects of this particular project is that we've done the design collaboratively with an interdisciplinary team, including technologists, instructional designers, and even a faculty member or two.

Here's a pic of our screen designs and the application state diagram:

I'll break this down into detail in upcoming posts.

Next up: Iterative design.

I'm starting a strong push to institute Unit Testing in a relatively new project; I figure it will be easier to really get into the habits in a new project from the start, rather than trying to steer some of our ancient existing projects in that direction right away. But I've hit a snag... where should I keep the test classes?

We've been using Subversion to manage our project files since shortly after I started here... getting us into source control was one of my first imperatives. So our code is laid out nicely in folders:

In the src folder, I have things organized in packages like

So where do I put the test cases? I could put them in a test package at the root of the project:

But what I'm really leaning toward is mirroring the main folder structure of the package in a test package in the root of the repository, at the same level as the src folder:

My thinking is that the classes in the test package would not get deployed with my actual project code, so they shouldn't be in the real source package tree. But I'm still not sure.

So I've landed on a new project. We've been asked to port a well-studied scientific algorithm into a Web Service, hoping to link the calculated results into a networked client for visualization (likely Google Earth).

Now, porting the algorithm (from MATLAB) should be relatively straightforward. What I'm unsure about is where to start building the Web Service! I've previously just used ColdFusion for anything that needed to serve a data feed (like sending RSS or feeding a Flash or Flex app), but the requirements from the contracting agency really point to something more portable like Java, Python or Ruby. Since I'm most familiar with Java, and there have been a few articles here and there on Java Web Services, that seemed to be a likely path.

I've read about SOAP, REST, and XML-RPC, and the Apache Axis library. Then I found Axis2, and heard about CXF from a colleague. Can anyone offer any advice as to where to start? Does anyone even build Web Services by hand anymore?

Oh, and Barry... I know I still owe you those 8 things you asked about.