In response to Dave's update...
Responding to the RDF bits, I guess RDF/XML makes what you're trying to express a bit more verbose, but it's hard to call it difficult. It'd end up being...
...with 'director' as an rdf:type, and 'name' being the property/relation to the subject "12345.html"; or, in Turtle/N3...
<12345.html> a :director; :name "John Hughes".
I'd recently worked out a different XML serialization -- http://asynchronous.org/rx/ -- for RDF that is a little more concise for data that's mostly properties, and not so much about rdf:types. It also does not allow mixed-content, but it doesn't require node-typing and thus element-striping; it would allow you to say...
... though that would result in the Turtle...
<12345.html> :director "John Hughes".
Frankly, I like the version with "name" involved better, but it's your data-model. :)
In any case, I see a bit more how this is specifically about REST, but I'd still argue that it's more about change-handling in coarse-grained API design. If in a [local] procedural approach you may have...
Film.setName( String newName ); Film.setYear( int newYear );
... the argument goes that in a remote-procedural environment you should really, and only, just have ...
updateFilm( Film newFilmData );
... to cut down on network round-trips, update overhead, synchronization/coherency concerns, &c.
So there is an interesting issue about how much of a representation -- either the whole representation or just the changed aspects -- need to be given back to the server. I guess it's really a function of the server's capabilities, as well as an assessment of the client's capabilities, as well as what's reasonable for the application/API.
Back to a "RESTful" worldview, one way to go is simply say "PUT back the whole representation", which as you're saying can be weird. Reasonably, the server may ignore [either silently or loudly] changes to some fields. An optimization of this may be to used something like RFC3229 to be more ... um ... optimal.
Another way to go would be to put something inline in the representation -- either a form or indiciation that a certain convention is supported -- that effectively says to the client "hey, you only need to send changed fields on update" or "here are the change-allowed fields" or something.
I'd consider these both RESTful, since both are talking about a constrained interface, placing the semantics in the media-type and document content, and using hypermedia as the engine of application state. The former certainly implies more server- and client-side smarts, and the latter is certainly what the web does. I guess if I were trying to be pedantic, I would call the later more RESTful, since the server is directing the client about how to proceed ...
... but this is also the point I start to get into trouble about RESTful API design. In traditional RPC/RMI environments, the client is built with a specific understanding and knowledge of the API space. In the web, a human sits just past the client-side UserAgent, and interprets the generic HTML and forms that come back. I believe there is an intersection of those two, but I'm having trouble finding it.