http://example.org/database/1 (303 redirect to...)
http://example.org/database/1/ (2XX returning the blob)

Got those URIs working? Now go into the code for the latter and add this:

if (request.getHeader("Accept") == "application/rdf+xml") {

 <rdf:RDF
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns:owl="http://www.w3.org/2002/07/owl#">
    <owl:Thing rdf:about="http://example.org/database/1" />
 </rdf:RDF>

} else {
    blob
}

That unnamable thing you've been calling "1" now has a useful globally-unique HTTP identifier that establishes its presence on the Semantic Web as Linked Data.

Now comes the conjuring trick I saw my colleague Andrew Houghton performing. Free your mind of the idea that this blob is one "thing" and write an elevator speech describing the use cases for the blobs. If your blob is XML, look at the element names to help you write the speech. Circle the important nouns in the speech and peer into the blob looking for such a thing. If you think you see one, append the noun to the latter URI with a "#" like so:

http://example.org/database/1/#noun1
http://example.org/database/1/#noun2

etc.

Now that these meaningful names have actionable HTTP identifiers, we need to announce their existence inside the <rdf:RDF> like so:

<owl:Thing rdf:about="http://example.org/database/1/#noun1" />
<owl:Thing rdf:about="http://example.org/database/1/#noun2" />

You've just conjured up meaningful things out of the blob and given them Linked Data names using semantically-rich HTTP URIs. Granted, some of the semantics implied in the URI aren't reflected in the RDF, but that is easily remedied. And if somebody says you are lying about the existence of noun7 for record 53, update your code and/or the blob to fix the bug (it's not a "lie" since it wasn't intentional). Apologize and explain to them that conjuring always has been and always will be an inexact science. ;-)

This "Conjuring" pattern is a trustworthy starting point for making the important things lurking inside your blobs discoverable and available for unexpected reuse.

The second answer changes if you buy into the "Web Document vs. Real World Object" conception of Linked Data: "is this identified thing a Web Document?" "yes" (2xx), "no" (303 or hashURI) or "I don't know" (4xx).

As a client looking at response codes, I can't really know which interpretation the Linked Data URI designer intended. Nevertheless, as a coiner of Linked Data URIs, we need to choose one or the other (and hopefully not waffle and use both.)

Which interpretation would you choose? Keep in mind that "document" can be modeled as an abstract concept and thus identified as a "Real World Object" using 303 links to a variety of "Web Document" representations.

Understanding new use cases is easy.
Finding names for new things is hard.

Finding names for new things is easy.
Understanding how new things fit in with old things is hard.

Understanding how new things fit in with old things is easy.
Figuring how to move old things into new things is...
(now where did I leave that thesaurus?)

1. the words (names) people use when talking about use cases


2. how those named things need to be related to one another in order to satisfy a set of use cases


3. how existing names and relationships can best be adapted to accommodate new use cases


4. the value of extending, constraining, instantiating existing abstractions to maximize unexpected reuse


5. whether or not things should be named and behave on a wire

Hmm. What am I forgetting?

In the investing domain, the assumption is that every investment portfolio has a risk-return profile that can be optimized in line with an "efficient frontier". Again, I don't fully understand why, but something tells me this makes sense in spite of (or more likely especially in) these tough economic times.

Regardless of the times, it seems to me that these principles are somehow related. There must be an efficient frontier for any given hype cycle. It's not clear how anyone can measure this, but without having a handle on it we are making wild guesses about resource allocations.

OTOH, I don't want anyone to get the impression that I sit around thinking about the connection between hype and efficiency all day long. It's just an idea that popped into my head. What I sit around all day thinking about is ways of producing and consuming Linked Data efficiently. This is the hype cycle that I hope without hope is being managed efficiently.

Recall that the primary things named in a domain model fall into a handful of categories: class, instance, attribute, relationship, operation, and the model itself. The Grails scaffold automatically provides HTTP URIs for Web document representations for some of these things. Here are examples using the default Grails URI mapping:

Model Web Document

http://example.org/

Class Web Document

http://example.org/{className}/{operationName}

Instance Web Document

http://example.org/{className}/{operationName}/{instanceName}

[Beware that Grails names these path segment tokens based on analogous MVC concepts:
{className}={controller}
{instanceName}={id}
{operationName}={action}
Also beware that the default Grails URI patterns are deficient in other ways, but it is difficult to change them. As a result, the URI patterns below are reluctantly forced into the default mold.]

The first enhancement for Linked Data compliance is real world object identifiers support for everything in the model. For some domain model categories 303 (See Other) redirect behavior is appropriate:

Real World Model

http://example.org/{modelName}/rwo

Real World Class

http://example.org/{className}/rwo

Real World Instance

http://example.org/{className}/rwo/{instanceName}

These can be implemented by creating a special controller for the {modelName} and adding a new content-negotiable "rwo" action to it and the default scaffold controller. Real world object URIs for attributes and relationships can then piggy-back on Real World Class as hash URIs:

Real World Attribute

http://example.org/{className}/rwo#{attributeName}

Real World Relationship

http://example.org/{className}/rwo#{relationshipName}

Now that real world object identifiers are defined for everything in the domain model, the only thing lacking is an RDF representation alongside the scaffold's HTML representation. This will be examined in a subsequent post.

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

One of the interesting differences between these two ultimate classes is that Web standards allow for direct instantiation of "resource" whereas Java requires you to subclass java.lang.Object before you do so. Java is also nice, compared to say C++, because it restricts multiple inheritance. If the Web had a similar constraint, the Semantic Web would be a whole lot simpler because a singular rdf:type could be required instead of optional or duplicitous.

My modest proposal, then, is to change Java and Web standards ever so slightly. In the case of Java, let's forbid developers from subclassing java.lang.Object and force them to subclass java.lang.Goop or java.lang.Concept instead. My sense is that most experienced developers would proudly choose to subclass java.lang.Concept and would make a genuine effort to justify this claim.

Likewise, in the case of Web standards, let's deny developers the right to directly create HTTP URIs and force them to choose between GOOP and CONCEPT URIs instead. The protocols associated with the identifiers should be identical. Looking around the Web, I suspect we could solve the problem of world hunger by eating Web developers who confuse the two.

It certainly isn't true that a 303 redirect allows me to conclude that the identified resource is a "Real World Object".

I agree that HTTP 303 See Other does not allow clients to "conclude" that the URI identifies a RWO. This requires evidence of the server's intent which is currently expensive to obtain. One of the goals of Linked Data Architecture (LDA) is to make this intent more transparent and discoverable, but that is a different story.

What 303 does allow, though, is for clients to "assume" that the URI identifies a RWO. The Web Document at the other end of the 303 must contain information of substance about the (assumed) RWO in at least a tangential way or else the server wouldn't have bothered to redirect the client there. Granted, this is a weak form of "aboutness" but it is "aboutness" nonetheless and can be strengthened by the server over time as appreciation grows of the significance of Real World Object URIs.

The same principles apply to the use of hash URIs to identify Real World Objects.

Moving on to some of Pete's other points, he gives an example of a ringbinder on this desk. This Real World Object is easily transformed into a Web resource by assigning it an HTTP URI that returns a 303 redirect to another URI that identifies the corresponding "information resource". These are two different resources (related by "aboutness") and in his example it would be semantically sensible for the latter (information) URI to return 404 Not Found without compromising the Web identity of the RWO. If and when information about the RWO becomes available (e.g. an OCR PDF or MARCXML representation), the information resource can be updated and the identity of the RWO URI will be strengthened.

On the topic of a Web document that describes another Web document, I think this is an interesting use case that deserves a blog entry of its own.

On the topic of a URI identifying an HTML document that returns "gobbledygook", we need to accept httpRange-14's decision that that every Web document is an information resource and understand that information is invariably about something. The fact that the information resource is non-nonsensical doesn't justify ignoring httpRange-14 and say it isn't really an information resource after all, nor does the fact that the Real World Object it presumably describes is currently anonymous and nonsensical. Anonymous and nonsensical Real World Objects exist in abundance and we could start to make headway on some of them if we went to the trouble of assigning them names (HTTP URIs) and returning whatever information we have regardless of its apparent incoherence.

On another topic, I agree that a Web document may describe several RWOs, but nevertheless the Web document as a whole describes a RWO in its own right, namely the aggregation of those RWOs. The fact that nobody bothered to assign an HTTP URI to this aggregation (presumably with 303 behavior in this case) doesn't mean the RWO doesn't exist.

As subtle and philosophical as these issues may sound to others, I am pretty sure Pete and I would agree that discussing them and hammering out a common understanding is vital to leveraging the Web with maximum efficiency.

Jeff

Since a CRUD model is integral to the HTTP specification, the need for AtomPub may seem counterintuitive. In fact, the AtomPub CRUD model does not replace the HTTP CRUD model, it just explains how to apply it to Web resources that exist in the context of "collections". This need originated in the blogosphere where developers wanted to manage Web documents known as "blog entries" in conformance with the HTTP CRUD model. Fortunately, the AtomPub specification did not couple tightly with this type of Web document and developers are slowly realizing it can be used to manage any collection of Web documents.

[As an aside, a create, update, and delete model also lies at the heart of SRU Update. The key difference is that AtomPub chose to build on Web standards whereas SRU Update chose to build on SOAP standards. If you are wondering if SRU Update is for you, consider the fact that the SRU Update CrUD model will end up getting tunneled over HTTP despite the competing models. Why add the overhead?]

Getting back to an earlier point, people are realizing that AtomPub is effective at managing collections of Web documents other than blog entries. What may not be obvious is that there are other types of Web resources besides the familiar Web documents we all know and love. Specifically, Linked Data tells us that Real World Objects can also be identified as Web resources. Just as AtomPub accommodated the mental migration from blog entries to Web documents, it is equally effective for managing collections of Real World Objects. If it's not clear how this can be done, start with this earlier blog entry and watch this blog space for followups.

The first thing to note is that a collection in Atom(Pub) maps directly to a "class" in DM. There is no need to subclass in DM to accomplish this relationship. Likewise, a member in Atom maps directly to an "instance" in DM. Again, no subclassing is necessary.

The discussion becomes easier we set aside the create, update, and delete capabilities of AtomPub for the moment. We can do that because AtomPub mostly just tells us is how the URIs we need to support the Atom Syndication Format should react if we throw POST, PUT, and DELETE at them instead of GET.

Given this simplification, an Atom Feed is merely a representation of a class (collection) and an Atom Entry is merely a representation of an instance (member). It's just another representation that could/should be negotiable from a Generic Document that it shares with the text/html, text/xml, application/json, or any other representation that the server thinks is worth supporting. From the (MVC) controller POV, Atom is just another type of view (representation format) that it needs to produce from the model. Creating a class in DM that subclasses Atom would be equivalent to subclassing text/html or application/json. It's not necessary.

Note that unlike httpRange-14, a Linked Data interpretation requires additional, but relatively lightweight, assumptions on the Architecture of the World Wide Web. Here are at least some of them:

1. Clients can unambiguously classify a resource as a Real World Object (RWO) either by the presence of a hash in the HTTP URI (deduced prior to the HTTP request) or an HTTP 303 See Other status in the response (deduced after the HTTP request). In comparison, an HTTP 200 OK can be used to unambiguously classify the resource as a Web Document/Information Resource.


2. This implies that Real World Object vs. Web/Document/Information Resource are disjoint.


3. Every Real World Object needs to have at least one associated Web Document/Information Resource that contains information about it.


4. Every Web Document describes one RWO. The fact that some of these RWOs are mash-ups doesn't change this fact. Traditional understandings of the Web commonly fail to identify these Real World Objects with HTTP URIs.


5. The Web Document returned by dereferencing a RWO URI is expected to contain information about the RWO. Linked Data/httpRange-14 do not split hairs between data and metadata. It is all just information and information is invariably about something in the real world.

One of the beauties of embracing the Linked Data assumptions as a matter of policy is that they benefit others who may not even be aware of their significance.

Jeff

The harmonization of AtomPub and domain modeling provides a powerful model for discovering high-resolution resources that are suitable for "unexpected reuse". Here is a feed of the "person" class/collection with a single "instance/member" named "alice".

<feed xmlns="http://www.w3.org/2005/Atom">
  <id>urn:uuid:D9A1E60A-5F8A-4361-8CC6-E28EFD66B3AE<id>
  <title>Person Instances</title>
  <author><name /></author>
  <updated>2009-04-28T00:00:00.0Z</updated>
  <link rel="self" type="application/atom+xml"
    href="http://example.org/view/person/instances.atom" />
  <link rel="related" title="Real World Class"
    href="http://example.org/person" />
  <entry>
    <id>urn:uuid:FC3921ED-BD3F-4479-AE48-73AAA38EE19E</id>
    <title>Alice</title>
    <author><name /></author>
    <published>2009-04-28T00:00:00.0Z</published>
    <updated>2009-04-28T00:00:00.0Z</updated>
    <link rel="edit"
        type="application/atom+xml;type=entry"
        href="http://example.org/person/alice/entry.atom" />
    <link rel="edit-media" type="application/rdf+xml"
        href="http://example.org/person/alice/entry.datum" />
    <link rel="alternate" type="application/xhtml+xml"
        href="http://example.org/person/alice/default.html" />
    <link rel="alternate" type="text/n3"
        href="http://example.org/person/alice/default.n3" />
    <link rel="alternate" type="text/turtle"
        href="http://example.org/person/alice/default.ttl" />
    <link rel="related" title="Real World Instance"
        href="http://example.org/person/alice" />
    <content type="application/rdf+xml"
        src="http://example.org/person/alice/default.rdf" />
    <summary type="text" />
  </entry>
</feed>

Since the concept of domain model "class" maps to Atom "collection", we should expect them to appear as such in an Atom Service Document.Here is an example:

<service xmlns="http://www.w3.org/2007/app"
    xmlns:atom="http://www.w3.org/2005/Atom">
  <workspace>
    <atom:title>My Domain Model</atom:title>
    <collection href="http://example.org/person">
      <atom:title>Person</atom:title>
      <accept>application/rdf+xml</accept>
    </collection>
  </workspace>
</service>

Note that in order to accommodate Linked Data, the collection/@href refers to a Real World Class URI. This URI should do an HTTP 303 See Other redirect to a Class Generic Document from which the Atom feed Class Web Document shown above can be negotiated.

Ideally, the server root will act as a Model Generic Document for the model from which the Atom Service Model Web Document can be negotiated. The LDA resource categories for "model" are shown here:

The HTTP behaviors for these LDA categories can be found here.

Jeff Young
Andrew Houghton