[Fiware-ngsi] NGSI last open questions

[Tobias Jacobs]

Hi all,

The latest binding version is up.
https://forge.fi-ware.eu/scmrepos/svn/iot/trunk/documents/Ngsi10-RestfulBinding-Draft.docx

Note that the ../attributeDomains resource has disappeared, because it does not allow any interaction anymore and is a pure container.

Now the only real open issue left is the uniqueness of entity ID. I support the idea of submitting to it to the architecture board.

In case it is decided that only (id,type) is unique. NEC's preferred possibility to add type information to the access URI of an entity would be by using a parameter like "?type={typeName}". Systems with unique IDs can then simply ignore that parameter.

Best regards
Tobias


From: thierry.nagellen at orange.com [mailto:thierry.nagellen at orange.com]
Sent: Dienstag, 3. April 2012 10:11
To: boris.moltchanov at telecomitalia.it; jhierro at tid.es; denes.bisztray at nsn.com; Tobias Jacobs; fiware-ngsi at lists.fi-ware.eu
Subject: RE: [Fiware-ngsi] NGSI last open questions

Dear all,

First of all, I fully support the Boris' idea to submit the subject to the Architecture Board, especially because 5 or 6 Use Case projects should give relevant feedback in their area as they are involved in some dedicated IoT domains.

Regarding the topic itself which is what kind of Naming Service we need for IoT, each family of sensors/actuators try to have a unique naming service with no type because a unique type per family. The main question is "do we need a worldwide naming service or not?". For IP addresses or phone numbers we are using a single system with local freedom (length in digits, regional indicator...). We think it is possible to have a common European approach.

Juanjo: could we submit quickly this topic to the Architecture Board, for a short discussion and vote by email, not to stop the work on NGSI?

Thanks

Thierry

De : fiware-ngsi-bounces at lists.fi-ware.eu<mailto:fiware-ngsi-bounces at lists.fi-ware.eu> [mailto:fiware-ngsi-bounces at lists.fi-ware.eu]<mailto:[mailto:fiware-ngsi-bounces at lists.fi-ware.eu]> De la part de Moltchanov Boris
Envoyé : lundi 2 avril 2012 16:34
À : Bisztray, Denes (NSN - HU/Budapest); ext Tobias Jacobs; fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>
Objet : Re: [Fiware-ngsi] NGSI last open questions

Dear All,

I am sorry, we cannot assign unique ID for overall FI-WARE project on behalf of all partners and of the future of the FI. Sorry, I may not. Someone has to take this responsibility for such a decision and then design a registry for all types, domain IDs and unique IDs within FI-WARE.
I don't see a problem with type+ID on FI-WARE higher level.

And who will decide, define and take the responsibility to define, assign and control the overall Future Internet name space? And when the project finished?

I suggest do not limit the specification to the uniqueID and to have both possible: the uniqueID for IoT with a default IoT type or explicit type+ID for other domains, and leave it open to different types with their own IDs.

I didn't see Orange, that, as an operator with mobile devices and persons and not only sensor nodes, might have probably the same TI's vision with regards to this "voting". And anyway "Boris vs. Tobias+Denes" :) dispute is not at the same level of its importance and impact. This issue worth an Arch Board decision weighting all pro and cons and taking the responsibility for the consequences. And I hope this will happen, if this vision is different.

I understand that at this phase, in this specific NGSI related to IoT exercise it seems like a simplification, however it GREATLY impact on the interworking and interoperability therefore large scale propagation and validation of the project outcomes and of Future Internet (!) and complicates its Architecture with adding a new module for the name space allocation, name assignments and resolution.

We have to be careful.

BR,
B

From: fiware-ngsi-bounces at lists.fi-ware.eu<mailto:fiware-ngsi-bounces at lists.fi-ware.eu> [mailto:fiware-ngsi-bounces at lists.fi-ware.eu]<mailto:[mailto:fiware-ngsi-bounces at lists.fi-ware.eu]> On Behalf Of Bisztray, Denes (NSN - HU/Budapest)
Sent: Monday, April 02, 2012 2:43 PM
To: ext Tobias Jacobs; fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>
Subject: Re: [Fiware-ngsi] NGSI last open questions

Hi Tobias, All.


1.       So Orange, NSN and NEC is for the uniqueness of EntityID alone without the type. TI (Boris) is for ID + Type.  I believe we can assume that this is decided.



2.       I would not go into such an intricate philosophical debate. I support your approach on disallowed GET for now. Maybe we can come back to this when standardizing NGSI9. Going like this is a safe approach.

Best,
Dénes

From: ext Tobias Jacobs [mailto:Tobias.Jacobs at neclab.eu]<mailto:[mailto:Tobias.Jacobs at neclab.eu]>
Sent: Monday, April 02, 2012 2:37 PM
To: Bisztray, Denes (NSN - HU/Budapest); fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>
Subject: RE: NGSI last open questions

Hi Denes,

1. For us it is ok to assume uniqueness of EntityID.

2. You mean a GET on ../{entityID}/attributeDomains means "give me a list of all attributeDomains of this entity you have information about"? This is actually rather an NGSI-9 request, because it is on the availability of context information. I would try not to mix this. Of course we can still discuss about such a convenience function in NGSI-9 binding.
Here I would still rather go for either Martin's approach (return all attribute values, grouped by domain) or my approach (do not allow the request).

Best
Tobias

From: Bisztray, Denes (NSN - HU/Budapest) [mailto:denes.bisztray at nsn.com]
Sent: Montag, 2. April 2012 14:07
To: Tobias Jacobs; fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>
Subject: NGSI last open questions


Dear All,

As far as I remember we have only two open questions left with the NGSI-10 RESTful binding.

Let me elaborate on these two:

1.      Entity ID uniqueness

As previously mentioned I vote for the sole uniquenss of the Entity ID without the Type.

My reasons are:

a)      If we allow the type+ID combo-uniqueness the whole RESTful binding goes down the drain.

b)      I don't see real problems with having a unique name. I understand that having a phone and person with name Peter would make sense, but then what would the other all the other Peters doing? They have a name clash even within a single type.

2.      What should a GET on the /{entityId}/attributeDomains return

Tobias proposed not to return anything, Martin proposed to return all attributes ordered by domains.

I Currently there is no way to get a list of defined attributeDomains in an entity. Thus, we need some kind of method to get that list. However, returning all attributes as well is not good here, there are several ways to get a list of attributes. I propose the following response for the GET:

returnAttributeDomainsResponse

parts:

Part name: AttributeDomainList

Part type: String[0..unbounded]

Part name: ResponseCode

Part type: StatusCode

Please respond in this questions ASAP.

Best,

Dénes


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/fiware-ngsi/attachments/20120403/3f84722d/attachment.html>