[Fiware-iot] Status of UniSurrey ConfMan GEI wrt NGSI-9

[t.elsaleh at surrey.ac.uk]

Hello Fermin,

No, none that you mentioned.

Best regards,
Tarek



From: Fermín Galán Márquez [mailto:fermin at tid.es]
Sent: 04 July 2013 12:44
To: Elsaleh T Mr (Electronic Eng)
Cc: thierry.nagellen at orange.com; Salvatore.Longo at neclab.eu; fiware-iot at lists.fi-ware.eu
Subject: Re: [Fiware-iot] Status of UniSurrey ConfMan GEI wrt NGSI-9

Dear Tarek,

Just curiosity... are you supporting in your implementation also NGSI9 standard operations (in addition to convencience operations), including the ones related with subscribe context availability?

Best regards,

------
Fermín

El 04/07/2013 10:58, t.elsaleh at surrey.ac.uk<mailto:t.elsaleh at surrey.ac.uk> escribió:
Hello Thierry, All,

I would like to clarify the status of the GEI from UniSurrey, i.e. IoTDiscovery

Our current implementation has focused on the features defined in the technical roadmap for ConfMan GE that are based on semantic descriptions as this was our original planned contribution to FIWARE. And since there are no GEs in the IoT chapter that are involved in this, then from this perspective our current implementation is more or less a standalone enabler for any user who wants to register and discover IoT-A based semantic descriptions. There are other semantic-oriented enablers from the Data chapter, but I do not believe we are at the stage of integration with them at the moment.
The reason why we focused on the features that were not related to NGSI was that I understood that the all the features declared had to be collectively covered by the GEIs, meaning that if one GEI does one set of features, the other has to cover at least the remaining features.

With respect to NGSI-9 support, the currently supported bindings for our GEI are the following Convenience Operations:

* POST - //{serverRoot}/NGSI9/contextEntities/{EntityID}
* GET - //{serverRoot}/NGSI9/contextEntities/{EntityID}
* GET - //{serverRoot}/NGSI9/contextEntities/{EntityID}/attributes
* GET -  //{serverRoot}/NGSI9/contextEntities/{EntityID}/attributes/attributeName
* GET -  //{serverRoot}/NGSI9/contextEntities/{EntityID}/attributeDomains/{attributeDomainName}
* GET -  //{serverRoot}/NGSI9/contextEntityTypes/{typeName}

Updating registrations and specific discovery request restrictions like <operationScope> and <Association> have not yet been implemented, but are planned for R3.

In comparison to TID implementation, according to this spreadsheet<https://docs.google.com/spreadsheet/ccc?key=0Aj_S9VF3rt5DdEhqZHlBaGVURmhZRDY3aDRBdlpHS3c#gid=0>, their implementation supports (with updating, scope and associations):

GET    /ngsi9/contextEntities/{EntityId}
POST   /ngsi9/contextEntities/{EntityId}
GET    /ngsi9/contextEntities/{EntityId}/attributes
POST   /ngsi9/contextEntities/{EntityId}/attributes
GET    /ngsi9/contextEntities/{EntityId}/attributes/{attributeName}
POST   /ngsi9/contextEntities/{EntityId}/attributes/{attributeName}

Based on this I will liaise with NEC, to see how we can go about testing, despite the missing features.

Best regards,
Tarek




_______________________________________________

Fiware-iot mailing list

Fiware-iot at lists.fi-ware.eu<mailto:Fiware-iot at lists.fi-ware.eu>

https://lists.fi-ware.eu/listinfo/fiware-iot

________________________________

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/old-fiware-iot/attachments/20130704/5a0139c7/attachment.html>