Thierry all, during Wednesday discussion I mentioned that Fig. 7 could be re-arranged for clarification. Please find a proposal attached thought it is actually more a discussion and identification of open issues contribution... (a) Slide 2: Re-arrangement of the blocks Note especially the split into real-world aspects (right) and virtual aspects (left). (b) Slide 3: Adding IoT Application that can live on Device, GW, Backend (very much in line with ETSI M2M) (c) Slide 4: SENSEI Concept (at least my understanding) Please note: - one thing can have many devices associated with it. Best examples are "buildings with many sensors" - an IoT Resource is something than can be access, e.g. a device. A thing cannot be access, only the devices it is attached to. - a Virtual Entity is representing a complete Thing (d) Slide 5: After talking with an IoT-A member, I am not sure how to map concepts. See Slide 5. I color coded different mapping. IMHO it is either the black one or the blue one. The red one is wrong. Overall, I think the comparison with the IoT-A model shows that we are missing some of the concepts or are not clear on them. This includes the definition given in the Glossary and concept picture in Fig. 7. So what shall we do? Point is, if we communicate with the UC projects, we should have a good and stable vision. To be honest, I personally would try to harmonize the definitions and concepts with IoT_A as much as possible to avoid confusion in the community. The reason for that is that FIWare has NOT (!!!!!!!) the mission to do R&D and architecture work on IoT. FIWare ahs the mission to provide a platform with generic enable. This should be based on the outcome of former or running EU projects. (!!!!) Maybe I am too extreme here, but we should harmonize within the EJU not create division... One way out would be to reduce what we describe to real simple concepts. (a) Physical World <-> Virtual World View Thing <-> Virtual Entity (b) Deployment View IoT Backend <-> Iot Gateway <-> Device (c) API View IOT Resource + Event + Mng IF + Service IF Keep them separated for simplicity. What do you think? Ernoe - Ernoe > -----Original Message----- > From: Ernoe Kovacs > Sent: Freitag, 10. Juni 2011 15:23 > To: Ernoe Kovacs; thierry.nagellen at orange-ftgroup.com; fiware- > iot at lists.fi-ware.eu > Subject: RE: FIWare WP5 description > > Thierry, all, > > I think you asked for support during the PhC to identify the USP of FIWare > WP5. > > Please find a text file attached. It is basically extracting from the > existing text the major point and identifying what is different to others. > > > I am not sure where you want to include > this into the long text ("IoT SE v0.9 (v09_IOTSE.doc)"). > I actually suggest to have a text even befor the long explanation text, so > a section 3.1.1. > If we select that schema, then all sub-section should do it accordingly. > Alternative would be to have this as a summary at the end. > > Feel free to use and adapt the text. > - Ernö > > > > > > -----Original Message----- > > From: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot- > > bounces at lists.fi-ware.eu] On Behalf Of Ernoe Kovacs > > Sent: Mittwoch, 8. Juni 2011 11:42 > > To: thierry.nagellen at orange-ftgroup.com; fiware-iot at lists.fi-ware.eu > > Subject: [Fiware-iot] FIWare WP5 description > > > > Thierry, all, > > > > (a) short question: can we have a look at what other WPs are doing? > > I think it could be good to see how they deal with this complex process. > > > > Any hint where I can access that? > > > > (b) WP5 Work > > > > I am also not sure what is our main problem to tackle: > > (a) Interactions with the other WPs? > > - Purpose of this? > > - Level of Detail (Example: Easy to say I need security, more > complex > > to say I need "secure ids" or "distributed policy mng", even > > harder to say "a cryptographic secured identification schema") > > (b) WP internal architecture > > - I see pictures poping up right and left, all different, many not > > agreed on the large scope > > - internal interfaces > > You said you need to understand these internal interfaces. > > - Why? What purpose does it serve in the document? > > (c) Concept View > > - You said we need to explain to the UC project what they can > expect. > > This is a highlevel concept view, ideally with some good terms > and > > simple pictures. > > (d) Detailed Enabler View > > - which enablers, which sub-systems, which APIs, wich information > > model > > (e) Unique Selling Points > > - Again something different, and also completely different to > > present. > > > > > > Sorry for nasty question, but I am confused. > > - Ernö > > > > > > _______________________________________________ > > Fiware-iot mailing list > > Fiware-iot at lists.fi-ware.eu > > http://lists.fi-ware.eu/listinfo/fiware-iot -------------- next part -------------- A non-text attachment was scrubbed... Name: WP5 IoT Concept.pptx Type: application/vnd.openxmlformats-officedocument.presentationml.presentation Size: 435664 bytes Desc: WP5 IoT Concept.pptx URL: <https://lists.fiware.org/private/old-fiware-iot/attachments/20110610/039a7595/attachment.pptx>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy