IBM Support

Simple things generating complex behavior

Technical Blog Post


Abstract

Simple things generating complex behavior

Body

Apparently I have eclectic interests - at least people who know me seem to think so.  Arnaud LeHors from our Standards organization just published a blog entry on recent Linked Data Platform progress that brought me back to some concepts from chaos theory and power laws I was reading about recently. 

 

A short digression into chaos theory - optional

One of the really "crazy" things about chaos theory is that you end up with very complex behaviors from incredibly simple equations like image

 

There were slightly simpler forms in the book, but that's at home and I'm not.  The image above is from the Attractor Wikipedia page (scary math warning, if you follow that link there be dragons, as well as pretty pictures).  If you're attracted (pun intended) by that sort of thing, search the Web for information about occurrences of the Fibonacci series in nature, e.g. the petals of a flower.

 

Simple Concepts, Many Uses

  • Things (Web resources) come both alone and in collections.
  • Agents (users, browsers, programmatic clients) that act on those things can do an awful lot of things with just the familiar CRUD operations (Create, Read, Update, Delete)
  • Those CRUD operations are exposed consistently.
  • Programmatic clients (code not driven directly by a human) need unambiguous content in order to operate as intended

What makes it "hard" (read: complex) to describe those things is that real life does not operate literally at that level -- and machines are nothing if not literal.  The simple understandable form is an abstraction; it's useful for some things, insufficient for others.  Just like a compact car; great for gas mileage, not so great for moving your bed.

You will see those simple notions above all the time in IBM's linked data and OSLC interfaces.  They're in OSLC Core, so they're "inherited" by every OSLC domain specification.  Even where in products like Omnibus that expose Linked Data APIs (e.g. for an event collection), you see this pattern.  By the way, when I say Linked Data API I'm basically saying "looks like an OSLC spec, quacks like an OSLC spec, but there is no actual OSLC spec for that domain".  Jazz for Service Management uses them in its registries in the same way.

You might notice that the first 3 sound a lot like "REST" - not an accident.  The final one is more of a Linked Data thought.  AtomPub became a rallying point for exposing those concepts over HTTP for XML data.

 

So What's in It for Me?

Simple - re-use. 

  • Re-use of knowledge - the knowledge in your head, the knowledge captured and codified in code. 
  • Less learning curve - as you switch between "APIs", much of it's actually the same; what differs is the "class" and "property" names, although we pay attention to re-use there too.  Some of our product devs would say I pay aggressive attention to it.
  • Lower training costs
  • If you're a coder, more re-use of your own code means
    • Diminishing cost over time ... everyone's favorite "copy and tweak" method
    • You're faster responding to your stakeholders.

 

And this has What to do with this "Linked Data Platform" you started off with?

The Linked Data Platform is a World Wide Web consortium (W3C) standardization of these Very Simple Concepts that satisfy a surprisingly large set of scenarios ("aha, the point emerges" if you're a Tarentino fan).  The LDP specification no doubt looks "complex" to casual readers, but it's nothing compared to the specs for things we use every day like HTTP.  Specs are complex-looking because they're trying to serve many audiences, be very precise about both what they do cover and what they leave open.  Lots of options creep in as people try to apply it to their (existing and new) problems, factoring in what existing work they can build on to make implementations cheaper/better.  It takes work to be specific enough to write code against.  But casual readers are not coders; that's why it's becoming more common to have simpler companion documents like primers and, well, blog posts to help new readers ... be they casual ones or coders-to-be simply trying to get their bearings.

Because we're trying to address that fourth concept (machines need unambiguous content), and we want to do that while still allowing (even preferring) loosely coupled implementations, LDP is based on something called RDF, that underlies the Semantic Web.  This has the happy consequence of bringing an AtomPub-like level of interaction consistency for CRUD operations to machine-driven (automated) interactions that is fully consistent with the Semantic Web and simultaneously throwing off AtomPub's hard tie to XML ... RDF has multiple serializations, including but not limited to XML.

There's no LDP Primer yet, but the working group has documents of that sort (that title is mine, might well change) on its radar.  My best guess is they'll start showing up by this fall, but some are agitating for much sooner (June has been kicked around) so stay tuned.

 

 

[{"Business Unit":{"code":"BU050","label":"BU NOT IDENTIFIED"},"Product":{"code":"SSHPN2","label":"Tivoli"},"Component":"","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"","Edition":"","Line of Business":{"code":"","label":""}}]

UID

ibm11275556