Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

REST for Java developers, Part 4: The future is RESTful

The REST architectural style in the Semantic Web

By Brian Sletten, JavaWorld.com, 04/02/09

Page 3 of 5

There are several standard RDF vocabularies, but you are also free to write your own to describe whatever topic you would like. Chances are you will want to employ more powerful modeling constructs from languages like SKOS and OWL, but they all use RDF under the hood. RDF vocabularies can also be mixed and matched when and how you like. OWL can be used to equate terms and relationships, so once again we are not subjected to the Tyranny of the Common Form. It may seem like this would be chaos, but in practice it is quite organic, fluid, and manageable.

RDF graphs can be serialized to a variety of formats, but the N3 notation is pretty reasonable. Dublin Core is a set of terms created by a bunch of librarians who wanted to standardize how online resources were described. You can reuse their work by describing your RESTful services with their terms. There is no need to create a new concept of "creator" or "title." This code shows a series of three relationships (triples) expressed using the Dublin Core vocabulary:

@prefix dc: <http://purl.org/dc/elements/1.1/> .
<http://server/order> dc:creator <http://purl.org/people/briansletten> .
<http://server/order> dc:title "Acme Company Order RESTful system" .
<http://server/order> dc:created "2009-03-26T14:22Z" .

Well-designed vocabularies are almost as easy to read as prose. You can imagine reading the statements left to right:

• This service was created by Brian Sletten.
• This service's title is the Acme Company Order RESTful system.
• This service was created on March 26, 2009.

The difference is that they are just as easy for software to read and interpret. Software doesn't understand it as you do, but it is at least able to process, compare, and relate the terms based on the formalisms of the vocabulary and models.

With the freedom to pick and choose vocabularies or create your own -- and the ability to address RESTful services, data, business concepts, and so on -- you should begin to see how this approach satisfies many of the goals of the Web service stack. You can have a fabric of content, described in whatever terms are useful by anyone in the organization. There is no need to spend huge amounts of time up front selecting terms. People will gravitate toward what is used and what makes sense to them, and there are ways to equate different terms. The process is reasonably lightweight and flexible in the face of inevitable change.

To query RDF data sources, you would probably use the SPARQL query language. Even a casual introduction to SPARQL is beyond this article's scope, but if you are familiar with SQL, it will not seem that strange to you. Assuming you had a metadata storage system (such as the Oracle Spatial/RDF Engine, Sesame, Mulgara, OpenLink Virtuoso or the Talis Platform), you could query for all resources created by a specific user:

PREFIX dc: <http://purl.org/dc/elements/1.1/>
SELECT ?service
WHERE { ?service dc:creator <http://purl.org/people/briansletten> . }

Or you could query for who created a specific resource:

PREFIX dc: <http://purl.org/dc/elements/1.1/>
SELECT ?creator
WHERE { <http://server/order> dc:creator ?creator . }

By mixing and matching different vocabularies and the ability to query fairly arbitrary graph patterns, you will be able both to describe and to find a wide range of resources.