[Fiware-ngsi] QueryContext proposal

[Martin Bauer]

Dear all,

Sorry for the late reply which was due to NEC people being out-of-office or sick for roughly the past week.

I had a look at the proposal and I think the semantics is too complicated for applications. My general goal would be to keep things simple and enable well-behaving applications to continue working unchanged, if other well-behaving applications are being added.

So, for example, if an application has added an attribute and is continuously updating it, this should not stop working, if some other applications adds an attribute with the same name. Also, it should always be possible to add a new attribute regardless whether there is already one.

As a result, I propose to make the ID mandatory. This is not very nice, but simplifies the semantics quite a bit and prevents the undesired situations I mentioned above.

Regarding the NGSI background, I think this is an area that is clearly underspecified, leaving multiple possibilities open. I would not claim that the current NGSI specification makes any assumptions regarding A1 and A2. :(
I am not entirely sure, but I think this was due to time pressure and different opinions among the contributing parties - clearly not good.

It should be possible to cater for both cases, i.e. continuously updating a value so that there is always one attribute value, and keeping a time-series of values. For the latter, the timestamp could possibly be integrated into the ID, but this would require a certain convention. Using a pattern-based restriction on the ID, it could then be possible to request the whole time series by specifying the common part of the identifier only.

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: Tuesday, March 06, 2012 3:28 PM
To: Bisztray, Denes (NSN - HU/Budapest); ext Haller, Stephan; Tobias Jacobs; Martin Bauer; Farkas, Lorant (NSN - HU/Budapest); Zamani Farahani, Armin; fiware-ngsi at lists.fi-ware.eu; Tschirschnitz, Fabian
Subject: RE: QueryContext proposal

Is there any reply to this from NEC or Orange?
Otherwise I will assume the latest version of context update semantics sent by Stephan.

Best,
Dénes

From: Bisztray, Denes (NSN - HU/Budapest)
Sent: Friday, March 02, 2012 2:29 PM
To: 'ext Haller, Stephan'; ext Tobias Jacobs; Martin Bauer; Farkas, Lorant (NSN - HU/Budapest); Zamani Farahani, Armin; fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>; Tschirschnitz, Fabian
Subject: RE: QueryContext proposal

Stephan, All,

I understand your concerns with the metadata problem. Apparently, I support completely your last version of xls (well, not a bit surprise). I wonder what is the opinion of NEC and Orange.

Some addition to your questions:
A1: I think we have to assume it, otherwise we have a set of numbers without any differentiating factor. That is quite unintelligible.
A2: page 23, sec 5.5.3 only says that the TimeStamp, ID, Expires and ID is a set of reserved name strings for Context Metadata. Nothing about being compulsory.


a)      I think so.

b)      That is one scenario. Same ID, but different timestamp.

Best,
Dénes



From: ext Haller, Stephan [mailto:stephan.haller at sap.com]
Sent: Friday, March 02, 2012 10:32 AM
To: Bisztray, Denes (NSN - HU/Budapest); ext Tobias Jacobs; Martin Bauer; Farkas, Lorant (NSN - HU/Budapest); Zamani Farahani, Armin; fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>; Tschirschnitz, Fabian
Subject: RE: QueryContext proposal

Dénes,

I was not perfectly happy either with my proposal of taking the ID as THE way for identifying. However, let me explain why I considered this to be the lesser of two evils:

1.       The ID is one of the 4 meta data attributes officially defined in the spec. All implementations MUST support this meta data (but at run-time, attributes only MAY have such a meta data record). The spec also states that "Indicates the identifier of the contextAttribute."

2.       The other reserved meta data strings are Timestamp, Expires and Source. None of them qualifies for truly identifying an attribute - this is obvious for the two time values, but also for Source, as the same source may provide different attributes with the same name (example: source is "room controller", and it provides for "temperature values" with IDs "corner1", "corner2", etc.).

3.       I am very hesitant to allow a partial match without defining which meta data strings are involved. As indicated above, just a match on "timestamp" is certainly not enough! And defining which meta data (or combination thereof) is ok for a match is (next to) impossible.

The other two assumptions I made are
A1.  If we have several attributes with the same name, meta data MUST be present to be able to discern different attributes.
A2.  And a distinctive ID MUST be present in the meta data.

Maybe this assumption is wrong. Rethinking it - looking at the OMA spec - some more questions came up.

a)       Would it be ok to have in the context a time series of values? For example, the temperature value every hour (14:00, 15:00, 16:00, etc.) ?

b)      If yes, then the attribute name is certainly the same. But what about the ID? Will all measurements have the same ID or not?

Could some of the guys involved in OMA share some light on this assumptions as well as questions (a) and (b)?

If the answers are YES, NO, YES, YES [right assumption A1, wrong assumption A2, time series ok, same ID] as I have come to believe, then the table gets simpler again (and closer to what Dénes had originally...), as it would mean that we have to distinguish only between partial/no match or exact match on meta data. I made a version 2B of the Excel sheet reflecting this. The Excel can be ignored if the answers are not YNYY.

Regards,
-Stephan


Regards,
-Stephan


From: Bisztray, Denes (NSN - HU/Budapest) [mailto:denes.bisztray at nsn.com]
Sent: Freitag, 2. März 2012 08:40
To: Haller, Stephan; ext Tobias Jacobs; Martin Bauer; Farkas, Lorant (NSN - HU/Budapest); Zamani Farahani, Armin; fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>; Tschirschnitz, Fabian
Subject: RE: QueryContext proposal

Hi All,

I quite like the xls, thanks for the constructive feedback and expansion!

The only part I would refine a bit is the exclusivity of ID as an identification method. I'm not sure if it is a good idea to have one designated metadata that decides a match. I propose one modification:

The ID will be a prominent element, i.e. the current xls stays, but we cater for such cases when ID is not present in the attribute list, i.e. exact match of metadata, partial match of metadata is considered. The effect are essentially the same as the ID match and ID non-match.

Updated excel is attached.

Best,
Dénes



From: ext Haller, Stephan [mailto:stephan.haller at sap.com]
Sent: Thursday, March 01, 2012 5:26 PM
To: Bisztray, Denes (NSN - HU/Budapest); ext Tobias Jacobs; Martin Bauer; Farkas, Lorant (NSN - HU/Budapest); Zamani Farahani, Armin; fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>; Tschirschnitz, Fabian
Subject: RE: QueryContext proposal

All,

I have taken Denes input and added a few cases and compiled it to an Excel sheet as a basis for further discussion. Using Excel helps avoiding formatting issues you sometimes have when tables are included directly in e-mails.

To move forward, we should in my opinion use the following approach:

1.       Agree that tables in the Excel sheet cover all potential cases

2.       Agree how each case should be handled (fail / no fail)

3.       Agree on the REST details (error codes, operation to use)

4.       Update the Binding Word document with all the details

Some of the assumptions I made - on which we obviously also need to agree:

1.       A request should either be completely successful or fail (Atomicity). Handling of partially successful calls (e.g., "2 out of 3 attributes added") would become a nightmare (both on the client as well as for consistency reasons)

2.       Use the ID meta data attribute to check if two attributes are the same or not. If we have more than one attribute of the same name, they MUST have meta data with an ID, else we cannot distinguish them.

Regards,
-Stephan



From: Haller, Stephan
Sent: Donnerstag, 1. März 2012 10:07
To: 'Bisztray, Denes (NSN - HU/Budapest)'; 'ext Tobias Jacobs'; 'Martin Bauer'; 'Farkas, Lorant (NSN - HU/Budapest)'; Zamani Farahani, Armin; 'fiware-ngsi at lists.fi-ware.eu'; Tschirschnitz, Fabian
Subject: RE: QueryContext proposal

Denes,

I am in a long meeting all day today, so I will look at this carefully in the evening or tomorrow. One quick remark regarding the meta data match: I think we need to look at specific meta data elements - a match on something like "ID" or "Source" would likely indicate some other action than just a match on "timestamp"....

Any yes, I do realize that this is complicating things... :-(

Regards,
-Stephan


From: Bisztray, Denes (NSN - HU/Budapest) [mailto:denes.bisztray at nsn.com]
Sent: Donnerstag, 1. März 2012 08:48
To: Haller, Stephan; ext Tobias Jacobs; Martin Bauer; Farkas, Lorant (NSN - HU/Budapest); Zamani Farahani, Armin; fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>; Tschirschnitz, Fabian
Subject: QueryContext proposal


Hi all,

Here is my proposal for the queryContext semantics.

PLEASE READ CAREFULLY before replying.

Attribute mass replace scenario (either contextElements or /{contextElement}) level.

Note: the input as per page 22/sec.5.4.6.1 we assume only a set of ContextElements with the contained attributes and the update action type.

Note: in case the input ContextAttribute set of a ContextElement contains a set of ContextAttributes of the same name, then that ContextElement will fail in the ContextElementResponse structure with 400 Bad Request. (this is why the multiple value input with no metadata is not considered)

1.      Replace (update action), (PUT)

Input ->        One Attribute   Multiple Attibutes with same name
        no metadata at all      exact metadata match (one result)       partial metadata match (one result)     multiple result match   exact metadata match (one result per attribute value)   partial metadata match (one result per attribute value) multiple result match
One Attribute   replace replace Fail 409 / ?    Fail 409        Replace the matched ones        Fail 409 / ?    Fail 409
Multiple Attributes with same name      Fail 409        replace Fail 409 / ?    Fail 409        Replace the matched ones        Fail 409 / ?    Fail 409

Open question: what should happen to the Multiple Attribute Same Name input case with those attributes that are not matched?

2.      Append (append action), (POST)

Input ->        One Attribute   Multiple Attibutes with same name
        no metadata at all      exact metadata match (one result)       partial metadata match (one result)     Multiple result partial match   exact metadata match (one result per attribute value)   partial metadata match (one result per attribute value) multiple result partial match
One Attribute   Fail 400        Fail 409        Add new Add new Fail the matched ones with Fail 409, add the others     Add all Add all
Multiple Attributes with same name      Fail 400        Fail 409        Add new Add new Fail the matched ones with Fail 409, add the others     Add all Add all

3.      Delete (delete action), (DELETE)

Input ->        One Attribute   Multiple Attibutes with same name
        no metadata at all      exact metadata match (one result)       partial metadata match (one result)     Multiple result partial match   exact metadata match (one result per attribute value)   partial metadata match (one result per attribute value) multiple result partial match
One Attribute   Delete  Delete  Fail 409 / ?    Fail 409        Delete the matched ones         Fail 409 / ?    Fail 409
Multiple Attributes with same name      Fail 409        Delete  Fail 409 / ?    Add new Delete the matched ones Fail 409 / ?    Fail 409
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/fiware-ngsi/attachments/20120306/5b3ec883/attachment.html>