Hi Tobias,
The missing point is that you can have one attribute domain per entity. So the .../contextElements/device1/only_domain essentially is the same as .../contextElements/device1
Best,
Dénes
From: ext Tobias Jacobs [mailto:Tobias.Jacobs at neclab.eu]
Sent: Thursday, March 08, 2012 9:24 AM
To: Bisztray, Denes (NSN - HU/Budapest); Martin Bauer; ext Haller, Stephan; fiware-ngsi at lists.fi-ware.eu
Cc: laurent.artusio at orange.com; laurence1.dupont at orange.com
Subject: RE: AttributeDomainName problem
Hi Denes, all,
Sorry if I have missed some points in previous discussions, but I still do not see why the existing resource structure should not be suitable for querying all attributes of a domain.
Let assume that we have an entity "device1" and two attribute domains "device_info" and "vendor_info". Querying these domains would translate into GET operations to the resource
.../ContextElements/device1/device_info
and
.../ContextElements/device1/vendor_info,
respectively.
Best
Tobias
From: Bisztray, Denes (NSN - HU/Budapest) [mailto:denes.bisztray at nsn.com]
Sent: Donnerstag, 8. März 2012 07:47
To: Martin Bauer; ext Haller, Stephan; fiware-ngsi at lists.fi-ware.eu
Cc: laurent.artusio at orange.com; laurence1.dupont at orange.com; Tobias Jacobs
Subject: RE: AttributeDomainName problem
Hi Martin, Stephan, all,
Thanks for the insight. I completely understand that it would be good to query attributes via attribute domains. However, the RESTful binding in its current form makes it similar to querying a context element. Can you recommend where should we move the attributedomain queries? Maybe creating another root resource /attributeDomains in line with /contextElementTypes ?
Best,
Dénes
From: ext Martin Bauer [mailto:Martin.Bauer at neclab.eu]
Sent: Wednesday, March 07, 2012 9:22 PM
To: Bisztray, Denes (NSN - HU/Budapest); ext Haller, Stephan; fiware-ngsi at lists.fi-ware.eu
Cc: laurent.artusio at orange.com; laurence1.dupont at orange.com; Tobias Jacobs
Subject: RE: AttributeDomainName problem
Dénes, Stephan, all,
The primary idea of an attribute domain is that you can group context attributes with it and query / update
the whole group.
Context attributes can live without an attribute domain, i.e. there is no fixed structure relation enforced.
This means that in principle the same context attribute could be part of multiple attribute domains, it is
just a grouping after all. Whether you model it in such a way or whether context attributes in practice belong
to at most one / exactly one attribute domain is up to the one designing the concrete model / the one
implementing the system. NGSI itself keeps these options open.
However, as was rightly pointed out, the structure of a ContextElement allows to specify at most one
attribute domain and if it is present all context attributes belong to that attribute domain.
An Entity with context attributes belonging to multiple specified attribute domains therefore would have to
be represented by multiple ContextElements.
Regarding the REST binding, it should ideally be possible to query an attribute domain as you want to
get the whole set of context attributes grouped under this attribute domain.
Best regards,
Martin
------------------------------------------
Dr. Martin Bauer
Senior Researcher
NEC Europe Ltd.
NEC Laboratories Europe
Software & Services Research Division
Kurfürsten-Anlage 36
D-69115 Heidelberg
Tel: +49/ (0)6221/4342-168
Fax: +49/ (0)6221/4342-155
E-Mail: Martin.Bauer at neclab.eu <mailto:Martin.Bauer at neclab.eu>
http://www.nw.neclab.eu <http://www.nw.neclab.eu/>
*************************************************************
NEC Europe Limited
Registered Office: NEC House, 1 Victoria Road, London W3 6BL
Registered in England 2832014
From: Bisztray, Denes (NSN - HU/Budapest) [mailto:denes.bisztray at nsn.com]
Sent: Wednesday, March 07, 2012 11:23 AM
To: ext Haller, Stephan; fiware-ngsi at lists.fi-ware.eu
Cc: Martin Bauer; laurent.artusio at orange.com; laurence1.dupont at orange.com; Tobias Jacobs
Subject: RE: AttributeDomainName problem
Stephan, all,
There are two directions where this conversation need to go:
1. How to handle updates with different AttributeDomain.
I agree with your table. That is a reasonable assumption. About the question marked elements:
- When not present and the request contains AttributeDomainName, I'd update it to the new one.
- When present, and the request does not contain anything, I'd leave it. No change intention.
However, I'm not sure if present and the request also contains, we should make it fail. After all it is an ContextElementUpdate operation which should be able to update the context element, including its properties. If an update call with different AttributeDomain fails, then the AttributeDomainName is not changeable.
Is the always set policy too aggressive? I.e. if AttributeDomainName is present in request, then it will be updated, if not, the one present will remain?
2. How to change the RESTful binding
I would simply remove the AttributeDomain resource inside ContextElementId and ContextType. And that's it.
Best,
Dénes
From: ext Haller, Stephan [mailto:stephan.haller at sap.com]
Sent: Wednesday, March 07, 2012 11:12 AM
To: Bisztray, Denes (NSN - HU/Budapest); fiware-ngsi at lists.fi-ware.eu
Cc: ext Martin Bauer; laurent.artusio at orange.com; laurence1.dupont at orange.com; Tobias Jacobs
Subject: RE: AttributeDomainName problem
Dénes,
Yes, you are right - my oversight. The table in 5.5.1 clearly says that the AttributeDomainName is part of the ContextElement structure - hence, a ContextElement cannot have attributes from several domains.
The consequence on this is that if someone tries to update a ContextElement with a different AttributeDomainName, that call MUST fail. Less clear is what should happen when no AttributeDomainName has been specified:
Existing ContextElement
ContextElement in Update request
No AttributeDomainName
AttributeDomainName included
No AttributeDomainName
OK
Update and set attribute name?
AttributeDomainName set
Update?
OK if same name
Regards,
-Stephan
From: Bisztray, Denes (NSN - HU/Budapest) [mailto:denes.bisztray at nsn.com]
Sent: Mittwoch, 7. März 2012 10:52
To: Haller, Stephan; fiware-ngsi at lists.fi-ware.eu
Cc: ext Martin Bauer; laurent.artusio at orange.com; laurence1.dupont at orange.com; Tobias Jacobs
Subject: RE: AttributeDomainName problem
Hi Stephan, all,
Let me show the other side of the problem. If we look at the context query procedure, we realize that the queryContextResponse contains in the end a list of ContextElement structures. As I pointed out previously, one ContextElement can have one AttributeDomain.
So the update possibility Stephan pointed out is another problem. Subsequential updateContextRequests can have different domains on the same ContextElement. However, when queried by queryContextResponse, which AttributeDomain to give?
I don't want to restrict NGSI, but these facts point to the previous conclusion that one ContextEntity can have one AttributeDomain. The consequences definitely do simplify things, but that is unintentional.
Best,
Dénes
From: ext Haller, Stephan [mailto:stephan.haller at sap.com]
Sent: Wednesday, March 07, 2012 10:18 AM
To: Bisztray, Denes (NSN - HU/Budapest); fiware-ngsi at lists.fi-ware.eu
Cc: ext Martin Bauer; laurent.artusio at orange.com; laurence1.dupont at orange.com; Tobias Jacobs
Subject: RE: AttributeDomainName problem
Dénes, all,
I think this again points to a weakness of the NGSI spec. The lack of distinction between Attribute and AttributeDomain. Also in Figure 2, AttributeDomains are not mentioned.
Anyway, I read the spec as follows: In one single update operation, all attributes have to belong to the same domain (or none at all). However, in two consecutive updates on the same context element, you could add first attributes of domain 1 and in a second call then the attributes for domain 2.
But it certainly would simplify things if we would mandate that all attributes of a context element belong to the same domain. If an entity has attributes from several domains, then several context elements need to be created.
My main question is if we really need to make further restrictions on the standard spec. While I believe the resulting solution would be cleaner and simpler, I don't want to define anything non-compliant without a real need.
Regards,
-Stephan
From: Bisztray, Denes (NSN - HU/Budapest) [mailto:denes.bisztray at nsn.com]
Sent: Mittwoch, 7. März 2012 08:27
To: fiware-ngsi at lists.fi-ware.eu
Cc: Haller, Stephan; ext Martin Bauer; laurent.artusio at orange.com; laurence1.dupont at orange.com; Tobias Jacobs
Subject: RE: AttributeDomainName problem
A week has passed and got no reply to this mail.
In case there is no reply in 2 days, I assume that that the attributeDomainName is indeed an entity level property, and as such is not relevant for special address in the RESTful binding. Neither in the contextElementId nor the contextElementType resource.
Best,
Dénes
_____________________________________________
From: Bisztray, Denes (NSN - HU/Budapest)
Sent: Thursday, March 01, 2012 1:06 PM
To: fiware-ngsi at lists.fi-ware.eu
Subject: AttributeDomainName problem
Hi All,
Sorry for bringing up yet another topic, but I realised that the RESTful binding of the AttributeDomainName is a bit questionable.
The spec says (sec 5.5.1, pg 22):
AttributeDomainName (xsd:string) - Name of the attribute domain that logically groups together set of Context Information attributes. Examples of attribute domain are: device info (battery level, screen size, ...), location info (position, civil address, ...).
And below that at the ContextAttribute it says:
ContextAttribute [0..unbounded] - List of Context Information attributes. Note: In case of the attributeDomainName is specified all
contextAttribute have to belong to the same attributeDomainName.
So as it seems inside a ContextElement you have only one attributeDomain.
However, the restful binding puts in inside:
/contextElements/{contextElementID}/{attributeDomainName}
And says: Retrieve the values of all attributes of the context element belonging to the specific domain
This seems to be a conflict to me. ( i.e. if that attributeDomainName is queried that is specified in the ContextElement then all attributes are returned otherwise none?).
What if we move this one direction higher? i.e.
/contextElements/{contextElementId}
/contextAttributeDomains/{attributeDomainName}
(not in the same level of {contextElementId} to avoid the resolution chaos)
Best,
Dénes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/fiware-ngsi/attachments/20120308/3fd56db1/attachment.html>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy