Dear Tobias, I have filled a new proposal for that: https://forge.fi-ware.eu/plugins/mediawiki/wiki/fi-ware-private/index.php/OMA_NGSI_9/10_change_proposals#Proposal_10 Best regards, ------ Fermín El 25/02/2013 16:45, Tobias Jacobs escribió: Dear Fermin, Thanks a lot for putting this together. We basically agree with what has been written. However we are currently working on a detailed concept of how to represent associations (entity-to-entity-mapping for translating between Thing-level and Device-level information) in NGSI, and the semantics of the discovery operation will have to be slightly enhanced because of that. The associations with be expressed in the form of registration metadata, so whenever this special kind of metadata is present in the Registration, the NGSI-9 Server in IoT needs to react to that in a certain way. We will publish our proposal to this mailinglist this week. Best regards Tobias 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] On Behalf Of Fermín Galán Márquez Sent: Freitag, 22. Februar 2013 18:04 To: fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu> Subject: Re: [Fiware-ngsi] DiscoveryAvailabilityContext interpretation in OMA NGSI spec Hi, Once that we agree on this, I will try to rewrite my original paragraph on how the interpretation of discoverContextAvailability should be (changes in my previous paragraph in red): * If AttributeList is omitted, the discover operation returns all the context registration elements in which at least one of the entities in EntityId list match. Each returned context registration contains all the entities original registered in the given context registration except the ones not included in the EntityId list of the discovery operation and all the attributes in the original registration. * If AttributeList is not omitted, the discover operation returns all the context registration elements in which at least one of the entities in EntityId list match and at least one of the attributes in AttributesList match. Each returned context registration contains all the entities original registered in the given context registration except the ones not included in the EntityId list of the discovery operation and all the attributes in the original registration except the ones not included in AttributesList. Entity matching betwen R (in the query) and E (in context registration) is successful if the following conditions are satisfied: 1. R is a pattern and the ID of E matches the pattern, or R is no pattern and the ID or E equals the ID of R 2. The type of R is unspecified, or the type of E is unspecified, or both are specified and compatible. What compatible exactly means depends on the type ontology that is used; this is out of NGSI scope. Attribute matching between R (in the query) and E (in context registration) is successful if the following conditions are satisfied: 1. R name and E name are equal. 2. The type of R is unspecified, or the type of E is unspecified, or both are specified and compatible. What compatible exactly means depends on the type ontology that is used; this is out of NGSI scope. What do you think? Best regards, ------ Fermín El 22/02/2013 10:43, Ken Zangelin escribió: OK, no problem. We go with option 'a' then, right? Thank you Martin. BR, /KZ On 02/22/2013 10:39 AM, Martin Bauer wrote: Hi Ken, I was involved in the NGSI standardization activity. I don't think we discussed the concept of any kind of default type there, and in my (personal) opinion option a) is fitting better. 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: Athene, Odyssey Business Park, West End Road, London, HA4 6QE, Great Britain Registered in England 2832014 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] On Behalf Of Ken Zangelin Sent: Friday, February 22, 2013 9:35 AM To: Tobias Jacobs Cc: fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu> Subject: Re: [Fiware-ngsi] DiscoveryAvailabilityContext interpretation in OMA NGSI spec Hi there, yeah, I agree, Tobias is right. However, we need to decide. The implementation depends on the decision made. To me, personally, the option 'b' seems more logical. Also I am not insisting. The NEC team participated in creating the NGSI9/10, right? You are probably the partner with most knowledge of all this so perhaps we should let you make a decision? The faster the better; as I said, we need it in order to implement ... BR, /KZ On 02/22/2013 09:23 AM, Tobias Jacobs wrote: Hi Fermin, I think the underlying question is how to interpret a missing type field. The two possibilities are a) A missing type field means that the entity can be of any type b) A missing type field means that the entity is of some default type My proposal is a consequence of the assumption of a). However, I am not insisting on that assumption, so if there are good reasons for assuming b) we can also go for that. Best regards Tobias From: Fermín Galán Márquez [mailto:fermin at tid.es] Sent: Donnerstag, 21. Februar 2013 16:30 To: Tobias Jacobs Cc: fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>; Martin Bauer; Salvatore Longo Subject: Re: [Fiware-ngsi] DiscoveryAvailabilityContext interpretation in OMA NGSI spec Dear Tobias, One doubt regarding 2) in your proposal: There would other ways of comparing not typed entities. E.g. of alternative for 2): "The type of both R and E are unspecified, or both are specified and are equal". Why do you prefer your approach among others? It is just for understanding the rationale of your proposal... Thanks! Best regards, ------ Fermín El 18/02/2013 9:45, Tobias Jacobs escribió: Hi Fermin, We have exactly the same view on this, but we think that a more precise definition is needed of what it means when "an Entity in the EntityIdList is present". Our suggestion is to say that an EntityId E matches a requested EntityId R, if both of the following conditions are satisfied: 1) R is a pattern and the ID of E matches the pattern, or R is no pattern and the ID or E equals the ID of R 2) The type of R is unspecified, or the type of E is unspecified, or both are specified and compatible. What compatible exactly means depends on the type ontology that is used; this is out of NGSI scope. Best regards Tobias, Martin, Salvatore 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] On Behalf Of Fermín Galán Márquez Sent: Donnerstag, 14. Februar 2013 17:00 To: fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu> Subject: [Fiware-ngsi] DiscoveryAvailabilityContext interpretation in OMA NGSI spec Hi, I have found another case of poorly documented operation in the OMA NGSI specification, that I would like to expose to the list members to know what do you think. In particular, the description of discoverContextAvailability operation in section 5.3.2 defines the abstract format of the discovery in terms of ane EntityId list and a AttributeList, but not how that discovery has to be processed to produce the result. Our interpretation is as follows: * If AttributeList is omitted, the discover operation returns all the context registration elements in which at least one of the entities in EntityId list is present. Each returned context registration contains all the entities original registered in the given context registration except the ones not included in the EntityId list of the discovery operation and all the attributes in the original registration. * If AttributeList is not omitted, the discover operation returns all the context registration elements in which at least one of the entities in EntityId list is present and at least one of the attributes in AttributesList is present. Each returned context registration contains all the entities original registered in the given context registration except the ones not included in the EntityId list of the discovery operation and all the attributes in the original registration except the ones not incluced in AttributesList. Let me show this with an example. Let's consider that two registrations have be done with the following information: [cid:part11.03070004.08040905 at tid.es] Then the following discoveries (first and second column) will produce the following results (third and fourth column): [cid:part12.05050509.04060202 at tid.es] What do you think? Thanks! Best regards, ------ Fermín ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.fiware.org/private/fiware-ngsi/attachments/20130306/fd696ef5/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 2966 bytes Desc: not available URL: <https://lists.fiware.org/private/fiware-ngsi/attachments/20130306/fd696ef5/attachment.png> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 8886 bytes Desc: not available URL: <https://lists.fiware.org/private/fiware-ngsi/attachments/20130306/fd696ef5/attachment-0001.png>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy