Thinking some more about spimes, those product entities that exist individually in space and time. I can see they could lead to major changes in the way in which marketing data is collected, collated, stored, analyzed, and used.   Clearly, individual spimes and their wranglers will generate a lot of data as they interact with the world and report back (eg, via RFID and GPS), and that data could usefully form the basis for marketing knowledge and marketing action.   But the web changes everything.  Spime wranglers, being intelligent human beings and companies, could comment and reflect on their interactions; the social web allows them to meet each other, across space and across time, in the same way that a houseowner can “meet” the previous or future occupants of his house.    Likewise, intelligent spimes could also reflect on their interactions, and even wrangle less-intelligent spimes.
What software architecture is appropriate for this mass of data?   Clearly, we’d want to store all the data, regardless of its format, in databases.  My question is pitched at a higher level of abstraction than that of the databases.  We desire that multiple, independent agents (both people and devices) are able to access the data, to read it and contribute to it, and maybe to over-write it (assuming they have the appropriate authorizations).  Moreover, we want to be able to combine and reason-across the data generated by one spime, say a particular motor vehicle, with that of other spimes — say, other vehicles of the same model, or other vehicles owned by the same person, or other vehicles purchased in the same year, etc.   We’d also like to combine and reason-across the data generated by spimes in different product categories — all the durables purchased by the Smith family in their life, for instance, or all the products purchased in Main Street, Anytown, last week.
An obvious data architecture for multiple, independent reading- and writing-entities is a blackboard.  A blackboard architecture is a shared memory space which enables agents sending and receiving messages to be decoupled from one another, both spatially and temporally.   Exactly as a blackboard does, messages left on the blackboard are stored until they are erased, and so the long-dead can communicate to the living, who can in turn communicate to the not-yet-born.   Tuple spaces and the associated Linda language are an example of a blackboard architecture (implemented in Java as Java Spaces).  We could imagine that each spime has its own tuple space, partitioned into secure sub-spaces for different spime-wranglers, from manufacturers, through each spime owner or carer, to after-sales service providers and disposal agencies.  Access to spaces will need to be controlled, so that only authorized agents may write, read and erase data in their allocated partition.   Here we could use something called Law-Governed Linda, an enhancement of Linda designed to add security features, although this may be too rigid for products whose uses cannot be readily predicted in advance.   An architecture allowing access to a tuple space following an appropriate dialogue between the relevant agents may be more flexible.
So far, so good for the data storage and access.  But spimes and spime wranglers will generate enormous quantities of data, and analyzing all this data will require some effort.  Better then, to plan for this effort and automate as much of the data collation, aggregation, processing and analysis.   Here, I suggest we should use so-called Tuple Centres, which are intelligent Tuple Spaces, able to reason over the data they hold.  Because we will want to combine and analyze data arising from different spimes, these tuple centres will need to communicate with one another, and agree (or not) to allow their data to be aggregated. A multi-agent system (MAS) with agents representing each spime-space (ie, the tuple space of each spime), and, for many spimes, each partition of each spime-space, seems the most effective architecture.  This is because the interests of the relevant stakeholders (spime-wranglers, marketing departments, manufacturers and service providers, data protection agencies, the state, the law) will vary and a MAS is the most effective way to formally represent and accommodate these diverse interests in a software system.
There are many details still be worked for this architecture.  But even at this level, it is clear that the traditional marketing data warehouse architecture is not sophisticated enough for what is needed for spimes. Hence, my statement above that spimes could lead to major changes in the way in which marketing data is collected, collated, stored and analyzed.  Use of spime data I will leave for another post.
References:
TuCSon, developed at the University of Bologna, Italy, is a platform which enables fast implementation of tuple centre applications.