[Fiware-ngsi] AttributeDomainName problem

[Martin Bauer]

Hi Denes, all,

I made two slides, one showing the logical structure of an entity and the second showing how context elements represent (partial) views of the entity. I hope this helps in understanding the relationships.

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: Friday, March 09, 2012 1:54 PM
To: Martin Bauer; Tobias Jacobs; 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 Martin, Tobias,

Ok, let me sum up what we have (to be sure that I understand correctly):

-          An Entity is NOT a ContextElement

-          An Entity can be one or many ContextElement

-          The connection between an Entity and its ContextElements is not defined

-          A ContextElement has one AttributeDomain

Is that correct?
If it is, I really don't get why we talk about attributeDomainS in the RESTful binding such as:
.../ContextElements/device1/AttributeDomains/device_info

There is one attributeDomain.
Can someone have any idea how to express the connection between an Entity and its ContextElements?

Best,
Dénes


From: ext Martin Bauer [mailto:Martin.Bauer at neclab.eu]<mailto:[mailto:Martin.Bauer at neclab.eu]>
Sent: Friday, March 09, 2012 1:46 PM
To: Tobias Jacobs; Bisztray, Denes (NSN - HU/Budapest); ext Haller, Stephan; fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>
Cc: laurent.artusio at orange.com<mailto:laurent.artusio at orange.com>; laurence1.dupont at orange.com<mailto:laurence1.dupont at orange.com>
Subject: RE: AttributeDomainName problem

Hi Denes,

Tobias is right. ContextElement is a container for entity-related information. Such a container can contain at most one AttributeDomain. If it does, all attributes have to belong to that AttributeDomain. Nevertheless one Entity may have context attributes in multiple AttributeDomains, which then have to be represented in multiple containers.

If we want to make the difference between ContextAttributes and AttributeDomains more explicit, we have to
put different sub-resources, e.g.

.../ContextElements/device1/AttributeDomains/device_info
and
.../ContextElements/device1/ContextAttributes/deviceStatus


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: Tobias Jacobs
Sent: Thursday, March 08, 2012 11:39 AM
To: Bisztray, Denes (NSN - HU/Budapest); Martin Bauer; ext Haller, Stephan; fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>
Cc: laurent.artusio at orange.com<mailto:laurent.artusio at orange.com>; laurence1.dupont at orange.com<mailto:laurence1.dupont at orange.com>
Subject: RE: AttributeDomainName problem

Hi Denes,

The connection in my view is is that a ContextElement contains some information about Entities, but not necessarily all available information. For example, if a ContextElement appears inside a queryContextResponse, it contains only the attributes that have been queried in the queryContextRequest.

I will be traveling for the rest of the day and will be back to the discussion tomorrow.

Best
tobias

From: Bisztray, Denes (NSN - HU/Budapest) [mailto:denes.bisztray at nsn.com]<mailto:[mailto:denes.bisztray at nsn.com]>
Sent: Donnerstag, 8. März 2012 09:56
To: Tobias Jacobs; Martin Bauer; ext Haller, Stephan; fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>
Cc: laurent.artusio at orange.com<mailto:laurent.artusio at orange.com>; laurence1.dupont at orange.com<mailto:laurence1.dupont at orange.com>
Subject: RE: AttributeDomainName problem

Hi Tobias,

I'm confused then.

-          What is the connection between an "Entity" and a ContextElement datastructure? I assumed 1:1 connection

-          If it is an 1:n connection, how should we express it?

-          Is it supported by the standard? Page 24, sec 5.5.5 - EntityId/Type says: If EntityId uniqueness is only guaranteed in combination with Type, then Type SHALL be present.  - I understand this as only an option, not a recommendation.

Best,
Dénes

From: ext Tobias Jacobs [mailto:Tobias.Jacobs at neclab.eu]<mailto:[mailto:Tobias.Jacobs at neclab.eu]>
Sent: Thursday, March 08, 2012 9:51 AM
To: Bisztray, Denes (NSN - HU/Budapest); Martin Bauer; ext Haller, Stephan; fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>
Cc: laurent.artusio at orange.com<mailto:laurent.artusio at orange.com>; laurence1.dupont at orange.com<mailto:laurence1.dupont at orange.com>
Subject: RE: AttributeDomainName problem

Hi Denes,

To my understanding, only one attributeDomain can be expressed in the ContextElement Datastructure, but still one Entity can have attributes from several domains.

Best
Tobias


From: Bisztray, Denes (NSN - HU/Budapest) [mailto:denes.bisztray at nsn.com]
Sent: Donnerstag, 8. März 2012 09:31
To: Tobias Jacobs; Martin Bauer; ext Haller, Stephan; fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>
Cc: laurent.artusio at orange.com<mailto:laurent.artusio at orange.com>; laurence1.dupont at orange.com<mailto:laurence1.dupont at orange.com>
Subject: RE: AttributeDomainName problem

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]<mailto:[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<mailto:fiware-ngsi at lists.fi-ware.eu>
Cc: laurent.artusio at orange.com<mailto:laurent.artusio at orange.com>; laurence1.dupont at orange.com<mailto: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<mailto:fiware-ngsi at lists.fi-ware.eu>
Cc: laurent.artusio at orange.com<mailto:laurent.artusio at orange.com>; laurence1.dupont at orange.com<mailto: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]<mailto:[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<mailto:fiware-ngsi at lists.fi-ware.eu>
Cc: laurent.artusio at orange.com<mailto:laurent.artusio at orange.com>; laurence1.dupont at orange.com<mailto: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<mailto:fiware-ngsi at lists.fi-ware.eu>
Cc: Martin Bauer; laurent.artusio at orange.com<mailto:laurent.artusio at orange.com>; laurence1.dupont at orange.com<mailto: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]<mailto:[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<mailto:fiware-ngsi at lists.fi-ware.eu>
Cc: ext Martin Bauer; laurent.artusio at orange.com<mailto:laurent.artusio at orange.com>; laurence1.dupont at orange.com<mailto: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<mailto:fiware-ngsi at lists.fi-ware.eu>
Cc: ext Martin Bauer; laurent.artusio at orange.com<mailto:laurent.artusio at orange.com>; laurence1.dupont at orange.com<mailto: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<mailto:fiware-ngsi at lists.fi-ware.eu>
Cc: ext Martin Bauer; laurent.artusio at orange.com<mailto:laurent.artusio at orange.com>; laurence1.dupont at orange.com<mailto: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<mailto:fiware-ngsi at lists.fi-ware.eu>
Cc: Haller, Stephan; ext Martin Bauer; laurent.artusio at orange.com<mailto:laurent.artusio at orange.com>; laurence1.dupont at orange.com<mailto: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<mailto: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/20120309/d566e2b8/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: EntityVsContextElement.pptx
Type: application/vnd.openxmlformats-officedocument.presentationml.presentation
Size: 75548 bytes
Desc: EntityVsContextElement.pptx
URL: <https://lists.fiware.org/private/fiware-ngsi/attachments/20120309/d566e2b8/attachment.pptx>