API for RDF? don't do it!
i've been enjoying the well-written and reasoned posts by
@jeniT (Priorities for RDF),
@ldodds (RDF and JSON: A Clash of Model and Syntax), and
@webr3 (RDF API, JSON Serialization and Standardization)
on what the
focus should be for
RDF in the near term.
one of the items all three authors
bring up is the need for a shared RDF application interface (API).
don't do it!
a shared API seems a reasonable idea, but there's a big problem. and that problem is the Internet.
on widely distributed networks like the Internet, APIs are not what promotes adoption and inter-operability. in fact, they do the opposite by leading everyone to adopt the same tools and techniques in order to share information. plus, API models are basically implementations of classic local network technologies in the RPC style (e.g. CORBA, DCOM, RMI, etc.) and those local network models do not scale (technically or socially) on widely distributed networks.
what you need is a Hypermedia Type
one of the most effective and scalable ways to communicate on the Web is through MIME Media types. for example, HTML is an excellent example of a media type that scales for the Internet and supports hypermedia linking. not just navigational links but also templated links (for queries) and links for sending data back to servers for processing.
why is hypermedia important? because on widely distributed networks where the authors of clients, servers, and data are a disconnected and diverse community, the messages passed through the network do not just carry data. they also carry application control information . that's one of the reasons HTML has done so well for the last 15 years.
want fast adoption? do what Atom did
HTML is not the only registered hypermedia type - just one of the oldest (1995) and best-known. a relatively new hypermedia type, Atom (2005) , got an amazingly quick adoption rate by Web standards, becoming a key message exchange format in just a couple years. why? one of the reasons is that Atom has hypermedia controls built right into the specification. if RDF wants to gain traction quickly, the lesson seems obvious; explicitly support hypermedia within the message itself.
RDF hypermedia is not a new idea. as i pointed out earlier this year in my lightning talk (Do we need Hypermedia/Write-able RDF?) at the Linked Open Data (LOD) - W3C Track @ WWW2010, there have been a number of attempts to adress the need for robust read/write semantics in RDF messages (Baker, Hausenblas, and Inkster). there have also been attempts establish a static HTTP protocol mapping to SPARQL (SPARQL Protocol for RDF and SPARQL 1.1 Uniform HTTP Protocol for Managing RDF Graphs). yet none of these efforts have resulted in the kind of adoption that HTML or even Atom enjoy.
because the don't go far enough!
RDF will languish until it goes hyper
There is little doubt that that RDF is powerful and valuable. but i predict RDF will continue to suffer slow adoption rates and limited use (as it has for the last ten years) until work is done to bring the expressive power of the the full set of Hypermedia Factors to an RDF-based media type.
and i hope it happens soon. cuz i needs me some Hypermedia RDF!