{"id":134,"date":"2008-10-26T11:39:06","date_gmt":"2008-10-26T11:39:06","guid":{"rendered":"http:\/\/meeseeks:5080\/blog\/?p=134"},"modified":"2008-10-26T11:39:06","modified_gmt":"2008-10-26T11:39:06","slug":"a-data-architecture-for-spimes","status":"publish","type":"post","link":"https:\/\/vukutu.com\/blog\/2008\/10\/a-data-architecture-for-spimes\/","title":{"rendered":"A data architecture for spimes"},"content":{"rendered":"

Thinking some more about spimes<\/a>, 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.\u00a0\u00a0 Clearly, individual spimes and their wranglers will generate a lot of data<\/a> 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.\u00a0\u00a0 But the web changes everything.\u00a0 Spime wranglers, being intelligent human beings and companies, could comment and reflect on their interactions; the\u00a0social web\u00a0allows 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<\/a>.\u00a0\u00a0\u00a0 Likewise, intelligent spimes could also reflect on their interactions, and even wrangle less-intelligent spimes.
\nWhat software architecture is appropriate for this mass of data?\u00a0\u00a0 Clearly, we’d want to store all the data,\u00a0regardless of its format,\u00a0in databases.\u00a0 My question is pitched at a higher level of abstraction than that of the databases.\u00a0 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).\u00a0 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.\u00a0\u00a0 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.
\nAn obvious data architecture for multiple, independent reading- and writing-entities is a blackboard<\/a>.\u00a0 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.\u00a0\u00a0 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.\u00a0\u00a0 Tuple spaces<\/a> and the associated Linda<\/a> language are an example of a blackboard architecture (implemented in Java as Java Spaces).\u00a0 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.\u00a0 Access to spaces will need to be controlled, so that only authorized agents may write, read and erase data in their allocated partition.\u00a0\u00a0 Here we could use something called Law-Governed Linda<\/a>, 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.\u00a0\u00a0 An architecture<\/a> allowing access to a tuple space following an appropriate dialogue between the relevant agents may be more flexible.
\nSo far, so good for the data storage and access.\u00a0\u00a0But spimes and spime wranglers will generate enormous quantities of data, and analyzing all this data will\u00a0require some effort.\u00a0 Better then, to plan for this effort and automate as much of the data collation, aggregation, processing and analysis.\u00a0\u00a0 Here, I suggest we should use\u00a0so-called Tuple Centres, which are intelligent Tuple\u00a0Spaces, able to reason over the data they\u00a0hold.\u00a0 Because we\u00a0will want to\u00a0combine and analyze\u00a0data 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<\/a>) 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\u00a0most effective architecture.\u00a0 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.
\nThere are many details still be worked for this architecture.\u00a0 But even at this level, it is clear that the\u00a0traditional marketing data warehouse architecture is not\u00a0sophisticated enough<\/a> 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.\u00a0 Use of spime data I will leave for another post.
\nReferences:<\/em>
\nTuCSon<\/a>, developed at the University of Bologna, Italy,\u00a0is a platform which enables fast implementation of tuple centre applications.<\/p>\n","protected":false},"excerpt":{"rendered":"

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.\u00a0\u00a0 Clearly, individual spimes and their wranglers will generate a lot of data as they interact with the […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[14,47,48,76],"tags":[],"class_list":["post-134","post","type-post","status-publish","format-standard","hentry","category-computer-technology","category-market-planning","category-marketing-data","category-spimes","p1","y2008","m10","d26","h11"],"_links":{"self":[{"href":"https:\/\/vukutu.com\/blog\/wp-json\/wp\/v2\/posts\/134","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/vukutu.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/vukutu.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/vukutu.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/vukutu.com\/blog\/wp-json\/wp\/v2\/comments?post=134"}],"version-history":[{"count":0,"href":"https:\/\/vukutu.com\/blog\/wp-json\/wp\/v2\/posts\/134\/revisions"}],"wp:attachment":[{"href":"https:\/\/vukutu.com\/blog\/wp-json\/wp\/v2\/media?parent=134"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/vukutu.com\/blog\/wp-json\/wp\/v2\/categories?post=134"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/vukutu.com\/blog\/wp-json\/wp\/v2\/tags?post=134"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}