[Fiware-oasc-etsi] Outreach List for starting ISG CIM: obviously oneM2M, SmartM2M, GSMA, ... which others?

Lindsay Frost Lindsay.Frost at neclab.eu
Mon Jan 2 10:50:16 CET 2017


Dear all,

firstly, thank you Jose Manuel for the GSMA references which you provided back in November (see below) and which I added to my "to do" list. Finally I have integrated them into my fat "CIM Survey" .DOCX file which I will share on 10.01 (official start of ISG I hope!)

We should create a list of organisations and contact persons to make an "outreach" to as soon as we get our Agreements signed and ETSI makes the ISG official.

e.g. Jose Manuel, can you send me the contact details for the appropriate contact person
        of the GSMA IoTBDE project?

Anybody else who has contact details of people/organisations who may bring in useful
contributions, please speak up.

cheers
Lindsay
PS Happy New Year, I hope ;-)

________________________________________
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: JOSE MANUEL CANTERA FONSECA [mailto:josemanuel.canterafonseca at telefonica.com]
Sent: Mittwoch, 16. November 2016 19:48
To: gilles.privat at orange.com; Lindsay Frost
Cc: fiware-oasc-etsi at lists.fiware.org
Subject: Re: [Fiware-oasc-etsi] 161114 draft of ETSI ISG proposal for cross-cutting Context Information - proposed changes from Lindsay, to discuss FRIDAY

Hi,

First of all, thanks Lindsay for the effort. I think we are now closer … We need to check internally (quite busy now at the SCEWC) the new proposed wording. In the meantime some comments:

Wrt schema.org just to say that they intend to work on IoT related stuff, see

https://docs.google.com/presentation/d/1VlvASoabpTil7k-A5LJJUAkOD7zCahomPIn2wvLg_XE/edit?usp=sharing

slide 25 on. I think we can mention it as a good example of community-driven initiative and the value that harmonized data models are already providing to the Web. On the other hand, schema.org basic vocabulary can be a good starting point for any new schema development effort as we are already doing with the FIWARE Harmonized data models.

Wrt to related initiatives, now we are in a position to mention the IoTBDE Project of the GSMA Connected Living Programme.

http://www.gsma.com/connectedliving/iot-big-data/

you can see in that page links to the harmonized data models, architecture and NGSIv2 profile.

http://www.gsma.com/connectedliving/wp-content/uploads/2016/11/CLP.25-v1.0.pdf
http://www.gsma.com/connectedliving/wp-content/uploads/2016/11/CLP.24-v1.0.pdf
http://www.gsma.com/connectedliving/wp-content/uploads/2016/11/CLP.26-v1.0.pdf

Thanks, best

From: <fiware-oasc-etsi-bounces at lists.fiware.org<mailto:fiware-oasc-etsi-bounces at lists.fiware.org>> on behalf of "gilles.privat at orange.com<mailto:gilles.privat at orange.com>" <gilles.privat at orange.com<mailto:gilles.privat at orange.com>>
Date: Wednesday 16 November 2016 at 19:11
To: Lindsay Frost <Lindsay.Frost at neclab.eu<mailto:Lindsay.Frost at neclab.eu>>
Cc: "fiware-oasc-etsi at lists.fiware.org<mailto:fiware-oasc-etsi at lists.fiware.org>" <fiware-oasc-etsi at lists.fiware.org<mailto:fiware-oasc-etsi at lists.fiware.org>>
Subject: Re: [Fiware-oasc-etsi] 161114 draft of ETSI ISG proposal for cross-cutting Context Information - proposed changes from Lindsay, to discuss FRIDAY

The W3C  Web of Things group is still an “interest group” and  is due to morph into a more formal standards-track “working group”, in W3C parlance
They are in the business of defining both data models and APIs, as CIM should be. For the APIs they might draw upon the work of  the Hydra community group
I think it is good to mention W3C  because ETSI can understand that we could go with them if we cannot endure any more the kind of chinese torture they are inflicting upon us…

For schema.org , I think Jose Manuel is in touch with them : from ETSI viewpoint they are just a bottom-up adhoc alliance rather than a de jure SDO, yet  they are not weighed down  by the bureaucratic and legal baggage of traditional SDOs and it does make a difference in the speed with which they produce results…

De : Lindsay Frost [mailto:Lindsay.Frost at neclab.eu]
Envoyé : mercredi 16 novembre 2016 17:09
À : PRIVAT Gilles IMT/OLPS
Cc : fiware-oasc-etsi at lists.fiware.org<mailto:fiware-oasc-etsi at lists.fiware.org>; 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>)
Objet : RE: 161114 draft of ETSI ISG proposal for cross-cutting Context Information - proposed changes from Lindsay, to discuss FRIDAY

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> [mailto:gilles.privat at orange.com]
Sent: Mittwoch, 16. November 2016 16:04
To: Lindsay Frost
Cc: fiware-oasc-etsi at lists.fiware.org<mailto:fiware-oasc-etsi at lists.fiware.org>; 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>)
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:

[id: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.

________________________________

________________________________

________________________________

_________________________________________________________________________________________________________________________



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/20170102/a99ad7c6/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 96160 bytes
Desc: image001.png
URL: <https://lists.fiware.org/private/fiware-oasc-etsi/attachments/20170102/a99ad7c6/attachment-0001.png>


More information about the Fiware-oasc-etsi mailing list

You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy   Cookies policy