Declarative and imperative messages
This post is a continuation of the previous one.
We tend to think of some messages as declarative and others as imperative. For example, a message from a sensor tells the recipient what is sensed, so it seems to be declarative, while a message to an effector tells the recipient what it is supposed to do, so it seems to be imperative.
In symmetric situations, like the contrived example (see previously), the same message might seem declarative when seen from the sender’s point of view, but imperative from the receiver’s.
When designing (or verifying) a system one specifies what is supposed to happen when messages are transmitted over a channel, that is, which messages are supposed to be (or may be) sent by the sender, and/or what the receiver is supposed to do on receiving messages. The desired correlation between system parts is decomposed into one correlation between sender state and messages sent, and a second correlation between messages received and receiver state. The specification of one or the other of these is often called an interface specification. An interface specification either says what the receiver of a message is supposed to “do”, as a function of the message and the receiver’s state, or what the sender is supposed to send, as a function of its state.
This is all pedantic and maybe obvious, but thinking in this way has helped me understand a puzzle. When I was on the W3C TAG we had occasion to talk about both HTML and RDF (at different times). When RDF came up sometimes someone would speak about what “RDF processors” might do, as if such things were somehow analogous to “HTML processors”. This always struck me as very odd and somehow troublesome, but I could never articulate why. I think the reason the phrase “RDF processor” is jarring is clear now. HTML is an imperative language; its specification tells browsers (or processors) what they should do to correctly interpret an HTML message (document). The generator of the message is relatively unconstrained by the specification – it can send any message it likes, as far as HTML is concerned. RDF and its vocabularies are declarative; their specifications tell curators (or generators) what they should do to generate correct RDF. The consumer of the message is relatively unconstrained by the specification. So speaking of “RDF processors” in a discussion of web standards is as peculiar as speaking of “HTML generators”. Standards have almost nothing to say about what either kind of thing is supposed to do. Their correctness is not articulated by any standard, but rather is idiosyncratic to the particular system in which they’re embedded.
This leads to an odd but I think illuminating way of looking at RDF. What does it mean for something to conform to, say, the Dublin Core vocabulary? This is another puzzle that has been bothering me. RDF being declarative, the specification would apply to generators of DC-containing RDF documents, not to consumers. The Dublin Core spec says (in effect) that you shouldn’t write ‘X dc:creator Y.’ unless what ‘X’ means is the creator of ‘Y’ means, and so on. Because this condition is not usually decidable by machine, the “should” (conformance condition) applies not to a piece of software, but to an overall curation process, a system with human parts and mechanical parts, that leads to the generation of such a statement.
– There may be further installments, but I make no promises.