Hi Tobias and all, For your information, the ongoing "Semantic Extension of the the PubSub GE" discussion thread on this mailing list is related to an alternative approach which provides a natural solution to the "entity to entity associations" issue. This approach is based on transforming NGSI documents into RDF documents, and expose the PubSub GE as a Linked Data service. Linked Data is one standard technology to deploy the Open Data vision. Once expressed in RDF, PubSub data and context information will be interoperable with other sources of information which adopt the Linked Data standard (such as DBPedia, Geonames, ...). Back to our specific issue, defining relations among entities, is a core function of the RDF language (this has been reflected in the naming "Linked Data"). We will also elaborate on this work and publish it on this mailing list. Both approaches might then benefit from each other. Best regards, Fano De : fiware-ngsi-bounces at lists.fi-ware.eu [mailto:fiware-ngsi-bounces at lists.fi-ware.eu] De la part de Tobias Jacobs Envoyé : lundi 25 février 2013 16:45 À : Fermín Galán Márquez; fiware-ngsi at lists.fi-ware.eu Objet : Re: [Fiware-ngsi] DiscoveryAvailabilityContext interpretation in OMA NGSI spec 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] On Behalf Of Fermín Galán Márquez Sent: Freitag, 22. Februar 2013 18:04 To: 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:image001.png at 01CE141D.75723870] Then the following discoveries (first and second column) will produce the following results (third and fourth column): [cid:image002.png at 01CE141D.75723870] 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 _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.fiware.org/private/fiware-ngsi/attachments/20130226/84c9376a/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 2966 bytes Desc: image001.png URL: <https://lists.fiware.org/private/fiware-ngsi/attachments/20130226/84c9376a/attachment.png> -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 8886 bytes Desc: image002.png URL: <https://lists.fiware.org/private/fiware-ngsi/attachments/20130226/84c9376a/attachment-0001.png>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy