mca blog

the biggeset hurdle to effective machine-to-machine conversations over the Web is not infrastructure (Internet-level hardware is certainly a commodity now), application protocols (HTTP, SOAP, BITtorrent, the list goes on), or programming paradigms (Java, Ruby, Python, Erlang, MVC, MVVM, imperitive, declarative, static, dynamic, blah, blah, blah...). no, the real problem right now is media. as in media types. we have all the hardware, protocol stacks, and progamming tools we need but the variety and richness of media-types sharable over the Web has not kept pace.

deja vu all over again

the current disparity between media-type options and other Web-related decisions is similar to the hardware/software mismatch experienced throughout the 1980s and 1990s for desktop and server programming. there will always be an uneven advance in the various components of a system - the Internet is no exception. but, while hardware and software continued to march ahead over the last decade, the sophistication of the media types used to marshall information around has remained relavitely static. and this is becoming a serious problem.

sure, there have been some new data formats over the recent years; RDF, SOAP and, Atom are probably the best-known of the lot. but their actual impact has been limited and, in some cases, they don't even come close to addressing the real problem.

Atom

Atom "addresses[es] the syndication of Web content" and it does it very well. initally aimed at weblogs and news feeds, Atom (and the related AtomPub spec) is now used in a wide range of data exchange situations. the biggest drawback to Atom is that it has a very narrow semantic focus. it works well when applied to data that fits neatly into Atom's simple read-write model, but becomes unwieldy for data that relies on semantics beyond the CRUD-based operations of blogs and feeds.

RDF

RDF "is the W3C standard for encoding knowledge." it's popular with folks working to improve the value of data available on the Internet. however, RDF does very little to inform machines as to what machines can do with or do to the data. in other words, RDF does a great job adding meaning to the contents, but a poor job adding semantic meaning to the messsage that carries that content.

SOAP

SOAP "is fundamentally a stateless, one-way message exchange paradigm" and has been warmly embraced by the enterprise programming community for machine-to-machine conversations. it, too, has drawbacks. chief among these is the lack of useful semantics within the message. in fact, SOAP over HTTP ignores HTTP's application protocol semantics entirely (using HTTP only as a transport) and relies instead on a related spec (WSDL) to provide message semantics. this RPC-based out-of-band approach makes massive scaling and on-demand adoption of the content costly and difficult.

a lack of rich media semantics

the problem each of these well-known data formats share is a lack of rich media semantics. by media semantics i mean what message-parties can do with or do to the data in the message.

Atom does a good job of defining media semantics via the AtomPub (RFC 5023) specification. machines can infer Create, Updates, Read, and Delete operations on pre-defined URI elements. machines can also rely on a limited set of well-defined link relations in order to infer the meaning of other links within the message. RDF "does not assume any particular relationship between the denotation of a URI reference and a document or Web resource" and leaves these details outside the scope of the RDF media type. instead, SOAP relegates semantics to the secondary WSDL document and forces participants in SOAP messaging 'pre-build' clients and servers to match the WSDL semantics and 're-build' them each time the semantics change.

is X/HTML all we really have?

X/HTML (and its various cousins) does a very good job of capturing message semantics in a media type. good enough for Web browser to know when a link means the client can download data from the target URI (IMG, SCRIPT, OJBECT, IFRAME, etc.) and when a link implies a navigation to the target URI (A, FORM). the FORM element supports a selection of HTTP methods (GET or POST); the remaining linking elements support only GET. the LINK element itself uses the REL attribute to control behavior-switching in the client (e.g. rel="stylesheet").

this level of media semantics has allowed Web browsers to act as powerful agents on the WWW for more than a decade. but X/HTML, initially designed to mark up human-read documents, falls short when it comes to supporting machine-to-machine interactions.

what is needed are media types that support rich message semantics that machines can use to complete tasks.

what is needed are "semantic machine media types (SMMTs)."

good news and bad news

the good news is that all the required parts are available; all the players in place. it is possible to create SMMTs with today's technologies and standards. the bad news is that there seems to be very little positive activity in this area. instead i see projects to define new protocols or create extensions to existing protocols. i see new data formats that lack strong message-level semantics. i see people working with existing general media types attempting to add more meaning, but the link semantics are still missing.

these efforts (and others) are noble and sound; they solve real problems. but not the problem.

it seems we're stuck. someone needs to offer up some new media types that work for machines.

creating SMMTs

someone needs to start creating SMMTs that offer clear ways to locate and interpret LINK semantics (ala XHTML); SMMTs that provide support for clearly-defined, extensible, and easily parsed data elements (ala XML). ideally, SMMTs need not be tied to a single data format (XML, JSON, CSV, etc.) but instead can outline an abstraction layer that allows developers to create media types that follow similar standards for identifying data and hypermedia in ways that provides ways multiple data formats can support a wide range message semantics as well as set a groundwork for future, unanticipated needs.

SMMTs go beyond adding meaning to data; beyond supporting a small set of pre-defined semnatics; beyond creating one-off media that is set in stone and causes clients to break when updated.

that's the future of semantic media i want to sign up for.

who is with me?