[Fiware-ngsi] QueryContext proposal

[Haller, Stephan]

The 4 meta data names are compulsory in the sense that a system must be able to handle these meta data, and that these are the names to be used. While this is not stated clearly in section 5.5.3, in Appendix E this becomes quite clear: In section 5.5.3 is defined the ContextMetadata structure and a normative list of metadata for NGSI Context Management that shall be supported by all context components.

This doesn't mean of course that a system can expect these to always be present.

Regards,
-Stephan

From: Bisztray, Denes (NSN - HU/Budapest) [mailto:denes.bisztray at nsn.com]
Sent: Freitag, 2. März 2012 14:29
To: Haller, Stephan; 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

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; 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/20120302/3d820680/attachment.html>