May 19, 2010
"Conjuring" as a Linked Data design pattern
Domain Modeling, Linked Data
Everywhere I look there are blobs laying around that nobody quite knows what to name except "database", "record", or 1, 2, 3, 4, 5... Oh sure, some of these blobs are XML and they're indexed. Some of them are even accessible via a Web API using hackable query string parameters. Still, though, nobody's quite sure what to name the blobs. If you find yourself in a similar situation, try this:
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.
March 20, 2010
"Information" is not very helpful
Domain Modeling, Linked Data
If you buy into the "information resource vs. non-information resource" conception of Linked Data, the answer to the question "is this identified thing an information resource?" is either "yes" (2XX), "maybe" (303 or hashURI) or "I don't know" (4XX).
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.
March 19, 2010
Who invented "information"?
Domain Modeling, Linked Data
I've been ranting on the OpenURL listserv lately about the potential of Linked Data and occasionally making a fool of myself by referring to "information resource" when I really meant "non-information resource". What on earth was the person who originally coined the word "information" thinking? Didn't they know that Linked Data would come along someday and transform our understanding of reality based on the novelty of "non-information"? Couldn't they have invented a term signifying the negation of "information" instead so that people like me wouldn't get confused by people like me?
March 18, 2010
Life is like a box of use-cases
Domain Modeling
Finding new use cases is easy.
Understanding new use cases is hard.
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?)
March 12, 2010
You can't argue with use cases...
Domain Modeling, Linked Data
You can't argue with use cases. That's a pity, so I started a list of things I like to argue with instead:
- the words (names) people use when talking about use cases
- how those named things need to be related to one another in order to satisfy a set of use cases
- how existing names and relationships can best be adapted to accommodate new use cases
- the value of extending, constraining, instantiating existing abstractions to maximize unexpected reuse
- whether or not things should be named and behave on a wire
Hmm. What am I forgetting?
