- From: Rob Manson <roBman@mob-labs.com>
- Date: Sat, 21 Aug 2010 00:19:07 +1000
- To: public-poiwg@w3.org
Hi, great to see we're onto the "Next Steps" and we seem to be discussing pretty detailed structures now 8) So I'd like to submit the following proposal for discussion. This is based on our discussion so far and the ideas I think we have achieved some resolution on. I'll look forward to your replies... roBman PS: I'd be particularly interested to hear ideas from the linked data and SSN groups on what parts of their existing work can improve this model and how they think it could be integrated. What is this POI proposal? A simple extension to the "request-response" nature of the HTTP protocol to define a distributed Open AR (Augmented Reality) system. This sensory based pattern recognition system is simply a structured "request-response-link-request-response" chain. In this chain the link is a specific form of transformation. It aims to extend the existing web to be sensor aware and automatically event driven while encouraging the presentation layer to adapt to support dynamic spatialised information more fluidly. One of the great achievements of the web has been the separation of data and presentation. The proposed Open AR structure extends this to separate out: sensory data, triggers, response data and presentation. NOTE1: There are a wide range of serialisation options that could be supported and many namespaces and data structures/ontologies that can be incorporated (e.g. Dublin Core, geo, etc.). The focus of this proposal is purely at a systemic "value chain" level. It is assumed that the definition of serialisation formats, namespace support and common data structures would make up the bulk of the work that the working group will collaboratively define. The goal here is to define a structure that enables this to be easily extended in defined and modular ways. NOTE2: The example JSON-like data structures outlined below are purely to convey the proposed concepts. They are not intended to be realised in this format at all and there is no attachment at this stage to JSON, XML or any other representational format. They are purely conceptual. This proposal is based upon the following structural evolution of devices and client application models: PC Web Browser (Firefox, MSIE, etc.): mouse -> sensors -> dom -> data keyboard -> -> presentation Mobile Web Browser (iPhone, Android, etc.): gestures -> sensors -> dom -> data keyboard -> -> presentation Mobile AR Browser (Layar, Wikitude, Junaio, etc.): gestures -> sensors -> custom app -> presentation [*custom] keyboard -> -> data [*custom] camera -> gps -> compass -> Open AR Browser (client): mouse -> sensors -> triggers -> dom -> presentation keyboard -> -> data camera -> gps -> compass -> accelerom. -> rfid -> ir -> proximity -> motion -> NOTE3: The key next step from Mobile AR to Open AR is the addition of many more sensor types, migrating presentation and data to open web based standards and the addition of triggers. Triggers are explicit links from a pattern to 0 or more actions (web requests). Here is a brief description of each of the elements in this high level value chain. clients: - handle events and request sensory data then filter and link it to 0 or more actions (web requests) - clients can cache trigger definitions locally or request them from one or more services that match one or more specific patterns. - clients can also cache response data and presentation states. - since sensory data, triggers and response data are simply HTTP responses all of the normal cache control structures are already in place. infrastructure (The Internet Of Things): - networked and directly connected sensors and devices that support the Patterns Of Interest specification/standard patterns of interest: The standard HTTP request response processing chain can be seen as: event -> request -> response -> presentation The POI (Pattern Of Interest) value chain is slightly extended. The most common Mobile AR implementation of this is currently: AR App event -> GPS reading -> get nearby info request -> Points Of Interest response -> AR presentation A more detailed view clearly splits events into two to create possible feedback loops. It also splits the request into sensor data and trigger: +- event -+ +-------+-- event --+ sensor data --+-> trigger -> response data -> presentation -+ - this allows events that happen at both the sensory and presentation ends of the chain. - triggers are bundles that link a pattern to one or more actions (web requests). - events at the sensor end request sensory data and filter it to find patterns that trigger or link to actions. - these triggers or links can also fire other events that load more sensory data that is filtered and linked to actions, etc. - actions return data that can then be presented. As per standard web interactions supported formats can be defined by the requesting client. - events on the presentation side can interact with the data or the presentation itself. sensory data: Simple (xml/json/key-value) representations of sensors and their values at a point in time. These are available via URLs/HTTP requests e.g. sensors can update these files on change, at regular intervals or serve them dynamically. { HEAD : { date_recorded : "Sat Aug 21 00:10:39 EST 2010", source_url : "url" }, BODY : { gps : { // based on standard geo data structures latitude : "n.n", longitude : "n,n", altitude : "n", }, compass : { orientation : "n" }, camera : { image : "url", stream : "url" } } } NOTE: All sensor values could be presented inline or externally via a source URL which could then also reference streams. trigger: structured (xml/json/key-value) filter that defines a pattern and links it to 0 or more actions (web requests) [ HEAD : { date_created : "Sat Aug 21 00:10:39 EST 2010", author : "roBman@mob-labs.com", last_modified : "Sat Aug 21 00:10:39 EST 2010" }, BODY : { pattern : { gps : [ { name : "iphone", id : "01", latitude : { value : "n.n" }, longitude : { value : "n.n" }, altitude : { value : "n.n" } }, // NOTE: GPS value patterns could have their own ranges defined // but usually the client will just set it's own at the filter level // range : "n", // range_format : "metres" // This is an area where different client applications can add their unique value ], cameras : [ { name : "home", id : "03", type : "opencv_haar_cascade" pattern : { ... } } ] }, actions : [ { url : "url", data : {..}, // Support for referring to sensor values $sensors.gps.latitude & $sensors.compass.orientation method : "POST" }, ] } ] data HTTP Responses presentation client rendered HTML/CSS/JS/RICH MEDIA (e.g. Images, 3D, Video, Audio, etc.) At least the following roles are supported as extensions of today's common "web value chain" roles. publishers: - define triggers that map specific sensor data patterns to useful actions (web requests) - manage the acl to drive traffic in exchange for value creation - customise the client apps and content to create compelling experiences developers: - create sensor bundles people can buy and install in their own environment - create server applications that allow publishers to register and manage triggers - enable the publishers to make their triggers available to an open or defined set of clients - create the web applications that receive the final actions (web requests) - create the clients applications that handle events and map sensor data to requests through triggers (Open AR browsers)
Received on Friday, 20 August 2010 14:22:17 UTC