A "pre- and post-transcript" of discussion between Colin, Antranig and Clemens.
What we do have (suggested by Clayton some time ago) was the concept of a "materialization strategy" (which, when run in reverse, might be considered a "dematerialisation strategy). That is, this is what occurs when "model material" needs to be imaged into some external material (substance!) - which might be a database but even a "view" as traditionally conceived (the DOM). "Dematerialisation" might correspond to "instruments" - e.g. the stream of activities corresponding to mouse clicks needs to be transduced down into a stream of state. Our current challenge is to cast component configuration for the system itself as a "materialisation strategy" - then the system will be able to close upon itself as a self-contained declarative system (given components can themselves house transform and relay rules etc.)
Yes, that is a very good point. It's hard really to account for what is "more material" or "less material" than another thing... but ideally we want the stuff "inside" the materialisation boundary to behave more similarly to stuff "on the outside" so ultimately the relationship, one hopes, would become a more symmetric one. Each person, I imagine, on seeing stuff being imported from the other side of the boundary might consider that it has been "materialised".