Thanks Craig and Ben for this contribution, is a considerable step forward, however we have two major concerns on the proposed MQLv2 language that I think would deserve a careful analysis by the group. That would mean that your proposed deadlines are going to be extended. We don’t think that would be a problem, a problem would be to define a specification which is inconsistent or flawed since it was born and what it is worst, unimplementable using conventional technologies for instance, RDBMS. These concerns have been derived from careful analysis and by considering an experiment like the one which is described below: Experiment A simple data model of TrafficIncidences and Roads was defined. A 'traffic incidence' happens in a Road and a Road can be affected by many traffic incidences. Then a query like “Tell me the cause, road capacity" of the Traffic Incidences which happened on roads which severity was high or cause was ‘Vehicle collision’ and road capacity was greater than 2” We asked different engineers to express the query using SQL-like conventions and using the aforementioned MQLv2. All of them were able to describe the query very quickly in SQL terms Select cause, capacity >From TrafficIncidence, Road Where Road.id = TrafficIncidence.road AND severity = ‘high’ OR (cause = ‘Vehicle Collision’ and capacity > 2) but were in a trouble coming up to an expression like { “type”: “TrafficIncidence”, “severity”: “high", “cause”: null, “road”: { “capacity”: null } , “$or”: { “cause”: “Vehicle Collision”, “road”: { “capacity > “: 2 } } } Our experiment confirmed that the usability and developer friendliness of representing complex filters (AND, OR, etc.) using a JSON tree is essentially very bad. Furthermore it hardly meets the DRY principle (Don’t Repeat Yourself). On the other hand it does not meet the principle of separation of concerns as it mixes in the same structure and conventions the three different aspects a query must have, which are: 1/ What entity (or entity types) the query operates on 2/ What are the selected attributes 3/ What are the filter conditions So even though at first glance the MQLv2 syntax might seem nice at the end of the day it might turn into a double-edge sword. For instance, am I looking for traffic incidences which cause is unknown (null) or do I want the cause attribute in the query result objects? Or is severity going to be included in the result or not? So the MQLv2 language seems to be ambiguous and difficult to read. Second major concern ‘Implementability” De: <fiware-ngsi-bounces at lists.fi-ware.org<mailto:fiware-ngsi-bounces at lists.fi-ware.org>> on behalf of Craig Aldridge <caldridge at gsma.com<mailto:caldridge at gsma.com>> Fecha: miércoles, 5 de agosto de 2015, 17:21 Para: "fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>" <fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>> CC: Ben Howes <BHowes at gsma.com<mailto:BHowes at gsma.com>> Asunto: [Fiware-ngsi] GSMA contribution: New "Historic" API suggestions Dear all, Following on from the GSMA’s previous communication on suggested contributions to the NGSIv2 specification, we have been discussing in detail and have agreed with Telefonica a proposedway forward. It is felt that the best way forward is todevelop a new API that will deal with complex and historical queries rather than make breaking changes to the existing draft of the NGSIv2 specification. As such, please find detailed below (and attached) our thoughts on the new ‘Historic’ API. GSMA have evaluated several choices of language for the historic API query language by means of a weighted ranking matrix. The criteria which each query DSL was ranked by was based on requirements defined in collaboration with the FIWARE team at Telefonica. MQL and elastic search are the two main contenders as a result of this, however neither is perfectly suited. GSMA had already been working to create a specification (which you will see as MQLv2 in the ranking matrix) prior to involvement with FIWARE, which we feel offers a great choice of DSL to meet all the current requirements for querying, as well as offering scope to expand features in the future without breaking existing queries. The attached slides provide an overview of the 3 key areas GSMA have sought to improve in MQL, whilst the document shows in more detail how these improvements look from a more technical perspective, as well as some examples of these features in use. Can I please ask that this group review our suggestions and provide any feedback by no later than close of business on the 11th August; our target is to provide a full specification of the MQLv2 specification to this group by 14th August for final review. If you have any questions please feel free to be contact me, Kind regards, Craig Aldridge | Project Manager | IoT Big Data Ecosystem|GSMA | +44 7725 221 299 GSMA, Floor 2, The Walbrook Building, 25 Walbrook, London, EC4N 8AF PPlease consider the environment – don’t print this mail unless you really need to... This email and its attachments are intended for the above named only and may be confidential. If they have come to you in error you must take no action based on them, nor must you copy or show them to anyone; please reply to this email or call +44 207 356 0600 and highlight the error. ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.fiware.org/private/fiware-ngsi/attachments/20150806/a8eb8b22/attachment.html>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy