Dear Gilles, dear all, we could put in https://www.w3.org/WoT/ ? I am a bit hesitating to include schema.org because it has so many different areas and we (in ISG CIM) will probably need to focus on a few examples for reasons of time or fits-our-examples. What do everyone think about this proposed changes to text ? Any objections, let me know. W3C JSON-LD extends JSON, a serialization and messaging format, to serialize Linked Data (http://www.w3.org/TR/json-ld/). The Web-of-Things group www.w3.org/WoT/<http://www.w3.org/WoT/> could particularly collaborate with this ISG about enabling interoperability e.g. ISG CIM proposes a draft API and W3C-WoT comments or e.g. suggests means to translate towards other systems. ________________________________________ Dr. Lindsay Frost, Chief Standardization Eng. frost at neclab.eu<mailto:frost at neclab.eu> Mobile +49.163.275.1734 NEC Laboratories Europe, Kurfürsten-Anlage 36, D-69115 Heidelberg, Germany. Reg. Headoffice: NEC Europe Ltd, VAT DE161569151 Athene, Odyssey Business Park, West End Road, London HA4 6QE, Reg. in England 2832014 From: gilles.privat at orange.com [mailto:gilles.privat at orange.com] Sent: Mittwoch, 16. November 2016 16:04 To: Lindsay Frost Cc: fiware-oasc-etsi at lists.fiware.org; Mulligan, Catherine E A; Juanjo Hierro (juanjose.hierro at telefonica.com); Franck Le Gall (franck.le-gall at eglobalmark.com) Subject: RE: 161114 draft of ETSI ISG proposal for cross-cutting Context Information - proposed changes from Lindsay, to discuss FRIDAY Dear Lindsay Congrats for your steadfast commitment to make this happen! We are Ok with your edits on the Orange side A tiny remark : under W3C, it would be possible to mention the WoT interest group, they are doing things that are quite close and we should definitely liaise with them It might be possible to mention also schema.org under the alliances to liaise with , but is it tactically appropriate to mention it? De : Lindsay Frost [mailto:Lindsay.Frost at neclab.eu] Envoyé : mercredi 16 novembre 2016 14:13 À : Mulligan, Catherine E A; Juanjo Hierro (juanjose.hierro at telefonica.com<mailto:juanjose.hierro at telefonica.com>); Franck Le Gall (franck.le-gall at eglobalmark.com<mailto:franck.le-gall at eglobalmark.com>); PRIVAT Gilles IMT/OLPS Cc : fiware-oasc-etsi at lists.fiware.org<mailto:fiware-oasc-etsi at lists.fiware.org> Objet : RE: 161114 draft of ETSI ISG proposal for cross-cutting Context Information - proposed changes from Lindsay, to discuss FRIDAY Dear all, after talks with several ETSI people, I think some cosmetic fine-tuning (as attached) will get us into a good chance of success. We should please confirm/adapt them by Friday. Basically: (1) make the ToR visibly more open to different ideas outside of FIWARE, (2) show an intention not to deliberately duplicate oneM2M work, (3) build in a chance after one year for ETSI to adjust the ToR if there is strong need. Three principles on which no compromise is made: * work is contribution-driven, so nobody is forced to bring in non-FIWARE ideas. * work on the API and on data models is explicitly in parallel (i.e. NO "gating" before start API work). * the API and data models should be ready in Version 1.0 by end of the year. Please comment if you are NOT happy with any of the main proposed changes below, which are change-tracked (purple comments) in the document attached. If you are happy please also say so ... a) Page 3, clarify that software development is out of scope b) Page 4: the CIM layer is shown in a politically correct way (no mediation gateways, just Apps) c) Page 5, reference OMA as the initial inspiration, not necessarily the only one: d) Page 13: the overlap with oneM2M is admitted but said to be small e) Page 13: a direct read-out/control of smart-devices shall NOT be a requirement (minimal overlap to oneM2M) f) Page 13: later recognition (NOT necessarily adoption) by oneM2M is a goal g) Page 13, add some deliverables to show "inclusive" way of working and open review of progress/next steps h) Page 13: add a "Review" and "Version 2" option in year-2 so that after 12 months there is still change possible (should be attractive to ETSI) i) Page 17: stop emphasizing that FIWARE and ISG are "joined at the hip" DETAILS: (a) Page 3, clarify that software is out of scope The goal of ISG CIM is to develop technical specifications to enable other organisations [LF1] to develop interoperable SW implementations of a cross-cutting Context Information Management (CIM) Layer. (b) Page 4, replaced the figure with: [cid:image001.png at 01D2401D.49D4FC90] (c) Page 5, reference OMA as the initial inspiration, not necessarily the only one: As CIM interfaces, the abstract NGSI 9 and 10 interface specifications from OMA[1] will initially be evaluated. Others may also be identified. The Group Report will detect/describe the specification/standardization gaps in order to consider any missing features and to ensure interoperable SW implementations, including open source implementations. It is expected that an extension of OMA NGIS API involving expression using JSON-LD could aid interoperability, so this and potentially other extensions will be considered. [LF2] (d) Page 13, admit that there is a small potential overlap with oneM2M It is recognized, following technical discussions with oneM2M experts, that any sufficiently flexible CIM-API might also be used [LF3] to exchange information/commands directly with smart devices which contain software able to support the CIM-API. This kind of usage cannot be precluded (consider e.g. how use of SOAP messaging has been applied to IoT systems), however it is not the main purpose of the CIM-API. (e) Page 13, constrain the requirements in the informative phase (but the words are enough flexible): Therefore it is expected that no requirement for the CIM-API shall require a direct connection to a smart device[LF4] . (f) Page 13, state that later recognition by oneM2M is a goal To maintain a tight focus, the ISG CIM will at the end of the first and of the second year [LF5] make a review of its work and a proposal to ETSI on how to evolve the ISG CIM's future activities: · close the ISG, · or transfer the work and continue the activity in a (existing or new) Technical Body · or transfer the work, using appropriate ETSI mechanisms, to relevant group(s) within oneM2M[LF6] · or continue the ISG CIM for an additional period with (potentially revised) Terms of Reference (g) Page 13, add some deliverables to show "inclusive" way of working and open review of progress/next steps · (T0+01) Liaisons to major organisations (e.g. as in section 16 and others) informing fo the work and requesting comment/input. Invite participation/membership[LF7] . · (T0+05) Group Specification for a Context Information Management API (preliminary) together with a preliminary example data model (e.g. tourism)[LF8] · (T0+12) ISG CIM Review of Work and proposal to ETSI for next period (h) Page 13, correct the impression that all the main work is certainly over in one year (T0+18) Review of suitability [LF9] of the Group Specification and data models based on evidence gathered from (open source) software implementations (T0+22) If needed: Create and publish Version 2 of the Group Specification based on the previous Review. (T0+24) ISG CIM Review of Work and (if needed) proposal to ETSI for next period (i) Page 17, correct the fatal impression that FIWARE NGSIv2 is the only allowed outcome FIWARE (https://www.fiware.org/): The Context Information Management API of FIWARE (FIWARE NGSI API) is based on the abstract OMA NGSI API and can itself also be considered as a[LF10] possible [LF11] starting point for the CIM API. ________________________________ ________________________________ ________________________________ ________________________________ ________________________________ _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ________________________________ [1] http://technical.openmobilealliance.org/Technical/release_program/docs/NGSI/ V1_0-20120529-A/OMA-TS-NGSI_Context_Management-V1_0-20120529-A.pdf ________________________________ Emphasize that SW will not be developed in the ISG, but that the ISG will enable development of interoperable SW by others. Clarify that OMA NGSI 9 and 10 are starting points, with gaps which need to be identified and later filled. Allow other proposals also. Mention JSON-LD explicitly. Clarify that the views of oneM2M experts about potential overlap with Mcc have been understood. Insert this constraint on the CIM-API to make clear that every effort shall be made to avoid overlap and/or re-inventing the wheel. Inserted to ensure that the work is carefully compared with ETSI's ongoing roadmap and with the SDO landscape. Clarify again that contribution into oneM2M, using appropriate ETSI rules, is a highly desirable outcome. Inserted to gain more members and show ETSI a broad stakeholder membership. It also will ease acceptance/support of the ISG work in the other SDOs. Adding a preliminary data model makes (a) explicitly parallel work on API and models, (b) clear test candidate for external software developers. Clarify that even though the need is urgent now, there should be a later review of suitability of the CIM-API and some formal process to create a Version 2. It would be harmful to keep a less-than-satisfactury version in place simply because no plans existed for consensus-based update. Editorial change: FIWARE provides "a" starting point but the ISG should compare to others from member contributions, possibly from members not yet envisaged. The Phase 1 will look at gaps and may refer to several candidate API prototypes to clarify the gaps: (a) original OMA NGSI 9 and 10, (b) modified FIWARE versions (c) some other APIs not yet identified -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.fiware.org/private/fiware-oasc-etsi/attachments/20161116/3f541699/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 96159 bytes Desc: image001.png URL: <https://lists.fiware.org/private/fiware-oasc-etsi/attachments/20161116/3f541699/attachment.png>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy