Dear all, One of the due issues is the contribution of the FI-WARE Whitepaper. The announced timeline looks as follows: * generation of almost stable draft: October 26th * peer-review during week starting October 29th * target submission date: November 5th This whitepaper will be handled as a review/evolution of the contents in the "FI-WARE Product Vision" that is described in the wiki. These are the major actions that you have to carried out: · Drop general description of each of the GEs in the FI-WARE Product Vision. It is suggested that these contents are moved/merged with overview section of the Architecture Description of the GE (also part of its Open Specifications). This will save us from inconsistencies between contents of the Product Vision and the most recent Architecture Description and Open Specifications. · The FI-WARE Product Vision would just keep the overview section per chapter but this will be just the initial content. The idea is to add sections dealing with usage scenarios which describe, high-level, how GEs can be used in an encompassed manner to cover those scenarios. * TID made an initial proposal on the new sections to be added. A first draft/template of the target whitepaper is available at: https://forge.fi-ware.eu/docman/view.php/27/1333/FI-WARE+Product+Vision+New+Draft+12-10-01.docx It is particularly the second action Usage Scenarios on which you can already start to works. If there are further question please feel free to ask. I will answer or forward them and distribute the information. Best regards, Uwe PS Further background information From: fiware-wpl-bounces at lists.fi-ware.eu [mailto:fiware-wpl-bounces at lists.fi-ware.eu] On Behalf Of Juanjo Hierro Sent: Montag, 24. September 2012 18:11 To: fiware-wpl at lists.fi-ware.eu; fiware-wpa at lists.fi-ware.eu Subject: [Fiware-wpl] Approach regarding the whitepaper document about FI-WARE including description of common usage scenarios of FI-WARE GEs Hi all, I'll try to describe the approach that we have agreed to follow, after some discussion during our regular confcall this morning, regarding development of the whitepaper document about FI-WARE including description of common usage scenarios of FI-WARE GEs. Thanks to all those who contributed with rather good ideas that have helped to improve the approach proposed initially. In this description I will also give more details about the general approach that I had in mind. I hope they will help to get a better clue of how the whitepaper / product-vision document may look like. The whitepaper would come as a result of reviewing the FI-WARE Product Vision, so that the following changes would be introduced: 1. Introduction would stay at it is now (see http://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FI-WARE_Product_Vision). Note that it would provide a link to the "Overall FI-WARE Vision" where the basic concepts of FI-WARE would get introduced. 2. Regarding each chapter, we will keep for sure the "Overview" and "Terms and Definitions" section. We would essentially drop the contents linked to description of each individual GE that should go wherever it is appropriate in the Architecture Description of FI-WARE GEs (probably "Overview" and "Basic Concepts" sections) but we may also capture part of the description of each GE in the Overview section if suitable. 3. We will add per each of the chapters a number of sections each dealing with a description on how GEs in the chapter can be used or integrated, together or with other GEs from other chapters, in order to address a given common usage scenario. This sections will become "recipes" that a given application developer can read to understand how to address/solve a given scenario. Some of these scenarios will imply integration of GEs coming from several chapters, so we will have to make a choice regarding what is the chapter where description of the scenario will be more appropriate. Some examples of sections dealing with description of usage scenarios are the following (the title may change): * "Developing context-aware applications": here, we would elaborate on how several of the different GEs of the Data/Context Management chapter (particularly the Pub/Sub Broker GE, the CEP GE, the BigData GE, the Semantic Application Support GE and the Semantic Annotation Support GE) can be integrated together to support the notion of a "Context Managament Platform" that make it easier to develop context-aware applications. We would explain how data gathered by the Pub/Sub Broker GE may feed the CEP GE so that this last one can trigger actions based on detected scenarios, for example. We would also elaborate on how data generated by the CEP or the BigData GE may ultimately enrich context information, etc. The natural place where this section could fit is would be the chapter on Data/Context Management. * "Capturing data from the physical world and making it part of the context": here, we would elaborate on how data from sensors, captured through the IoT chapter GEs will feed the Context Broker, therefore the whole Context Management Platform we envision. We may place this section in any of the two chapters, the IoT or the Data chapter, but we would go for a compromise so that, for example, this section would go into the IoT chapter and would be referred from somewhere in the Data Chapter (for example, the section on "Developing context-aware applications" where we can mention that "part of the contextual information may come from physical objects. Check section on Capturing data from the physical world and making it part of the context" (text in blue would be link to the referred section) * "Supporting an Open Data approach": here, we would elaborate on how the envisioned Context Management Platform could be used to support an Open Data approach. We would elaborate on how organization willing to publish their data as open data would make that data available on a single Context Management platform linked to a FI-WARE Instance serving that purpose. We would also elaborate on how such FI-WARE Instance may bring GEs for the Apps chapter enabling services from the Context Management Platform to be published so that it becomes available to third parties and even end users ... Despite we would refer to GEs from the App Chapter, probably this section would fit more naturally as part of the Data/Context Management chapter, despite we may add a cross reference from the Apps Chapter * "Authenticaded access to APIs exported by FI-WARE GEs": here, we would elaborate on what architecture is supported that will enable authenticaded access control to APIs provided by the GEs, relying on usage of the Identity Management GE. The described architecture would be generic and should work for any GE, no matter what chapter it belongs to, but the description of the scenario would naturally fit as part of the Security chapter. * etc. 1. Telefónica will come with a first draft of the FI-WARE Product Vision where we will drop out all those contents from the current FI-WARE Product Vision which will not longer be kept as part of the FI-WARE Product Vision. We will try that this draft be available by Wednesday EOB. Together with this first draft, we will come with a list of "usage scenario" / "recipe" sections that we would like to propose for each chapter. Once agreed with the corresponding chapter leader, it will be up to the chapter leader to organize the work as to deliver the final contents of each section. Note that development of some of this "recipe" sections may require contribution by more than one chapter so they have to organize how contents will be developed (for example, section on "Supporting an Open Data approach"). Our suggestion is that the chapter leaders take the responsibility of providing a first draft of the section and then the other complementary chapters perform a peer review (following the same example, the Data/Context Management leader would provide a first draft of the section titled "Supporting an Open Data approach" and then the Apps Chapter Leader should review it). 2. We will share the table of contents derived from previous points with UC projects and will check whether they feel like there is some "usage scenario" / "recipe" section that is missing. This would allow us to arrive at the review meeting with a document that has been validated by UC projects. Of course, we would work on a copy of the FI-WARE Product Vision we will setup on the FI-WARE Private Wiki. We will replace the current FI-WARE Product Vision once a solid version is already available (may not contain all the final sections but at least consistent with the FI-WARE Architecture Description and Open Specifications) Let me repeat again the rationale behind this approach: I may be wrong, but I believe that the reviewers look for something that is relatively stand-alone. Something someone may read to get a clear vision about what we are envisioning in FI-WARE without too many references to other parts of the FI-WARE documentation. In this respect, I believe it would be difficult to develop such a target whitepaper without repeating a lot of the good stuff that was already there in the FI-WARE Product Vision document (which, I remind you, got overall good acceptance by the reviewers). On the other hand, introducing references to contents of the FI-WARE Product Vision doesn't solve the problem because we have found that peopled ends not reading the referred contents and, besides, even those sections on the current FI-WARE Product Vision that are in the best shape would still require some update. Bottom line: it would be difficult to generate the target whitepaper without reviewing at least partially the FI-WARE Product Vision, at least to keep some consistency between the whitepaper and the FI-WARE Product Vision, so let's make it a single exercise. Your comments/feedback is welcome. I will come with specific input regarding point 3 by Wednesday this week. Cheers, -- Juanjo ------------- Product Development and Innovation (PDI) - Telefonica Digital website: www.tid.es<http://www.tid.es> email: jhierro at tid.es<mailto:jhierro at tid.es> twitter: twitter.com/JuanjoHierro FI-WARE (European Future Internet Core Platform) Chief Architect You can follow FI-WARE at: website: http://www.fi-ware.eu facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 twitter: http://twitter.com/FIware linkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx Dr. Uwe Riss Senior Researcher, New Assets & Bussiness Model Innovation | SAP Research Karlsruhe SAP AG | Vincenz-Priessnitz-Str. 1 | 76131 Karlsruhe | Germany T +49 6227 7-70212 | F +49 6227 78-26158 | M +49 151 16810936 | mailto: uwe.riss at sap.com<mailto:uwe.riss at sap.com> www.sap.com<http://www.sap.com/> Pflichtangaben/Mandatory Disclosure Statements: http://www.sap.com/company/legal/impressum.epx Diese E-Mail kann Betriebs- oder Geschaeftsgeheimnisse oder sonstige vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrtuemlich erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine Vervielfältigung oder Weitergabe der E-Mail ausdruecklich untersagt. Bitte benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. Vielen Dank. This e-mail may contain trade secrets or privileged, undisclosed, or otherwise confidential information. If you have received this e-mail in error, you are hereby notified that any review, copying, or distribution of it is strictly prohibited. Please inform us immediately and destroy the original transmittal. Thank you for your cooperation. -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.fiware.org/private/old-fiware-apps/attachments/20121017/1517d981/attachment.html>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy