Help with the missing piece

Hello,
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?

Thanks,
Erik

P.S. Really enjoyed the REST track at QCon. Thanks to all that presented.