December 2, 2009

Domain Modeling and Linked Data

Domain Modeling, Linked Data

As a principle of object-oriented design, most things worth naming in a domain fall into one of several categories: class, instance, data type, attribute, relationship, or operation. Here is a Grails (domain) class example illustrating the patterns (excluding instance):

class Person {
	String name
	Organization employer
	
	String toString() {
		"${name}"
	}
}

Whether we realize it or not, the names assigned in this way form an ontology that uniquely identify everything in the domain. Also note that MVC frameworks like Grails automatically inject all domain classes with machine-level create, read, update, and delete (CRUD) operations. This accounts for the naming and persistence of instances as well.

Now that we know how to systematically name everything of interest in a domain, we need to realize that every one of those things identifies a real world object (RWO). Conversely, every RWO of interest in a domain can and should be named according to object-oriented principles.

The next trick is to take this machine-local ontology and project it onto the Web as Linked Data. Grails scaffolds provide a glimpse of how this can be automated by creating a parallel controller like so:

class PersonController {
	def scaffold = true
}

This effectively forces Grails to inject the domain class with globally-unique HTTP URI identifiers and CRUD behaviors. Unfortunately, the default Grails scaffold only provides HTTP URIs for Web documents that represent the real world objects. In contrast, Linked Data requires separate HTTP URIs for the RWOs themselves. The other problem is that it does not automatically provide an RDF representation.

Both problems can be solved by customizing the scaffold Controller with new actions to support content-negotiable RWO URIs and scaffold views that produce RDF. Details will be examined in subsequent posts.

Jeff