After a lot of reading and a lot of experimenting and a lot of deep thought, I believe I grok the REST architecture fairly well. I understand that URIs identify resources (nouns) that HTTP methods (verbs) act upon. But I'm having a little trouble with representing resources.
The naive approach would be to represent resources by serializing them to XML/JSON/format-of-choice and be done, but that really doesn't feel RESTful to me. Vanilla XML is no better at representing state than vanilla HTML would be; they both require specific knowledge of the semantics of the representation to be able to make any sense of it. Machine consumability goes right out the window.
As far as I can tell, the "solution" to this problem is to associate data (via XML namespaces or RDF or DAML or whatever) with existing ontologies like Dublic Core, FOAF, DOAC, OWL, SKOS, RDFS, etc. Then the data will at least mean something to anything expecting to consume the same ontology, assuming that I'm not trying to shoehorn the data into an existing ontology just to make it fit somewhere (e.g., one service uses dc:title to represent a job title while another uses it to represent a book title, and now whatever association exists between them is going to be broken).
Am I understanding this all correctly? Is the best way to describe my data to pick and choose from a dozen different ontologies and then make up my own to fill in the missing pieces? It seems like that's what dbpedia.org has done. It feels like doing it this way really misses the point since services just end up defining their own data types. AWS has a concept of "movie" which is pretty much the same as the Netflix concept of "movie", but there's no correlation between them unless I as a developer step in and manually create the connection, which defeats the purpose of typing data at all.
What am I missing?
P.S. Really enjoyed the REST track at QCon. Thanks to all that presented.