April 20, 2009
The Union of Domain Modeling, Linked Data, and AtomPub
[2009-04-28 - Replaced the "model" path segment with "view" to reflect the semantics better.]
[2009-04-20 - Added some extra examples for Class Web Document and Instance Web Document to provide additional clues.]
The union of Domain Modeling, Linked Data, and AtomPub results in an complementary set of use cases. To summarize, a domain model is a conceptual model of a system that can be described by visual representations called "class diagrams". Meanwhile, Linked Data establishes the Web identity of Real World Objects as distinct from traditional Web Documents that say something about the Real World Object. And finally, AtomPub establishes HTTP/1.1-compliant create, read, update, and delete (CRUD) operations for Web resources in general.
There are important synergies between these use cases. In essence, domain models identify resources according to semantically-rich categories like "model", "class", "attribute", "datatype", "instance" and "operation". The resources that are identified by the domain model can then be mapped mechanically to globally-unique HTTP URIs and those resources can then be managed with HTTP/AtomPub CRUD operations and discovered by an Atom Service Document and Atom Feeds. My colleague Andrew Houghton and I have identified a limited set of resource categories that are capable of supporting all of the Web application use cases that we can imagine. These use cases include Linked Data and Semantic Web support. We are calling this union of Domain Modeling, Linked Data, and AtomPub, the "Linked Data Architecture" (LDA).
Of the resource categories identified, six are fundamental and their behaviors are self-contained:
| Domain Modeling Concept | LDA Category Name |
|---|---|
| Class | Real World Class |
| Class Generic Document | |
| Class Web Document | |
| Instance | Real World Instance |
| Instance Generic Document | |
| Instance Web Document |
The first set of resource categories map directly to classes in a domain model, while the second set of resource categories map to instances of those classes in the domain model. Each resource category has a distinctive set of HTTP/AtomPub behaviors as expressed in the LDA Fundamental Behaviors table. These resource categories can be mapped onto consistent URI patterns. The following URI patterns are descriptive and designed for maximum "hackability", but are not prescriptive. Other URI patterns could be created, but the resource category behaviors associated with them remain unaffected:
| Domain Modeling Concept | LDA Category Name | Example URI |
|---|---|---|
| Class | Real World Class | http://example.org/person |
| Class Generic Document | http://example.org/person/ | |
| Class Web Document | http://example.org/view/person/about.html http://example.org/view/person/schema.xsd http://example.org/view/person/sru http://example.org/view/person/feed.atom etc. | |
| Instance | Real World Instance | http://example.org/person/alice |
| Instance Generic Document | http://example.org/person/alice/ | |
| Instance Web Document | http://example.org/person/alice/about.html http://example.org/person/alice/home.html http://example.org/person/alice/photo.jpg http://example.org/person/alice/about.json http://example.org/person/alice/foaf.rdf http://example.org/person/alice/entry.atom etc. |
If you imagine truncating the example URIs above you can start to imagine the use cases for some of the other categories which we will discuss in a later article. The information presented here is still in a raw form, but several people have expressed an interest. We are confident enough of the efficacy and consistency of these six categories to start making LDA available.
Jeff Young
Andrew Houghton
7 comments so far
Is it just me, or is having different URIs representing different things which differ only by a trailing slash... just asking for consumers of these URIs to be confused and end up using the wrong one?
Looks good - so far I can understand it... which is a pretty good test for abstract concepts :)
Shouldn't Class Web Document be http://example.org/person/firstname/default.html - and the others adjusted too? That seems to be the "naming convention" used for these URIs
Jonathan,
Think about how Apache automatically redirects the browser if you forget the slash on a "directory". In LDA, this redirect is a Linked Data Real World Object (without the slash) doing a 303 redirect to a Generic Document (with the slash). In these categories, every Real World Object MUST have a Generic Document and vice versa. This makes perfect sense! In other words, Linked Data comes for free with LDA.
Jeff
Tom,
The lack of symmetry in the example URI pattern for Class Web Document is intentional. What if Frank Zappa had named one of his kids "firstname"? We haven't explained how we address this issue yet, but the basic idea is to reserve a {modelName} token path segment (and a few others) to prevent these kinds of collisions.
Also remember that these URI patterns are descriptive, not prescriptive. You could invent your own URI patterns that conflate certain LDA classes, but then you need to deal with the ambiguities.
2) There are other LDA categories covering other use cases that you haven't seen yet. Some of the lost symmetry will be restored in the larger context.
Jeff
Are you suggesting personhood is conferred to http://example.org/person/alice by a hierarchy of URI segments? It can't only be that -- the resource representations have to be the ultimate descriptor of the type or kind of resource.
The URI structure is merely a reflection of the class/instance relationship. Clients should do an HTTP GET on the URI to obtain an explicit claim about the relationship. For example, the RDF representation should report rdf:about="http://example.org/person/alice" and rdf:type="http://example.org/person". In other words, http://example.org/person is a class in the example.org domain and http://example.org/person/alice is an instance therein.
Jeff
"Think about how Apache automatically redirects the browser if you forget the slash on a "directory". In LDA, this redirect is a Linked Data Real World Object (without the slash) doing a 303 redirect to a Generic Document (with the slash)"
So why not simply treating the "Real World Objects" in the same ways as when forgetting "the slash on a "directory"" and safing the unecessary communication overhead of a 303? ;)
Where is the difference? Let's treating "Real World Objects" like "directories".