Dear Martin
In the example you propose, we could actually have explicit links between the room entity ant the 2 sensors identified by their own URIs, and each of the sensors would have further properties in the RDF/JSON-LD sense that characterize their accuracy or temporal granularity as you suggest, these properties being typed according to well-known public ontologies (specified in an @context) rather than arbitrary metadata types. This is shown in the graph below (a variant of the example in the googledocs, provided by my colleague Wenbin)
If the room temperature is defined as a property of the room, apart from the sensors (as shown also in the graph) , it may also point to the sensors that provide the data (this is easily down in JSON-LD with a “@reverse” property pointing in the opposite direction from the RDF property which in this case identifies the range of the function provided by the sensors as a temperature)
All these properties will be gathered in a RDF graph maintained somewhere (independently of the main API entry points) like in IoTdiscovery and this would make it possible to respond to a SPARQL query specifying “I want room 1 temperature with an accuracy of 0,1°” by possibly providing the direct link sensor that provides this accuracy.
Also in this example you can see the expressivity of a description that is not limited to an arborescence like NGSI ( this graph is a Directed Acyclic Graph)
[cid:image002.png at 01D14E2B.631C62E0]
De : Martin Bauer [mailto:Martin.Bauer at neclab.eu]
Envoyé : mardi 12 janvier 2016 17:08
À : PRIVAT Gilles IMT/OLPS; Tobias Jacobs; RAMPARANY Fano IMT/OLPS; fiware-iot at lists.fiware.org; EXCOFFIER David IMT/OLPS; Toni Alatalo; Fiware-oasc-etsi at lists.fiware.org; fiware-ngsi at lists.fiware.org; MARTIGNE Patricia IMT/OLN; fiware-chapter-architects at lists.fiware.org
Objet : RE: [Fiware-ngsi] Preliminary proposal for evolution of FIWARE APIs and data models, based on JSON-LD --->version on a google docs document
Hi Gilles, all,
The question is what your distribution granularity is and for NGSI-9/10 the requirement has been
that the smallest unit is an entity/attribute pair --> This means that different devices may provide
different attributes for the SAME entity or even different values for the SAME attribute, i.e. there
can be multiple independent attribute instances at the same with very different metadata.
Use case example:
I put different sensors in a room and make them all accessible via NGSI-10. Each sensor registers itself with the registry
(IoT Discovery) using NGSI-9, providing the (same) Entity Id of the Room (e.g. “Room 123” in some kind of URI form)
and the attribute it can provide, e.g. “indoorTemperature”. If I put two temperature sensors, they both register the
attribute “indoorTemperature”. If I now want to access “Room 123 – indoorTemperature”, e.g. via the IoT Broker,
I should get both attribute values with their respective metadata back, e.g. one may have a higher accuracy, but
measure with a lower temporal granularity.
So, each sensor has a respective URL for its NGSI-10 interface and both offer information about the same entity with
the same URI. Thus it is not possible to just dereference this URI, i.e. use it as a URL, and access the information. Of course
it can be looked up and the respective URLs for accessing the relevant information will be found – which is what is done
in this example.
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-oasc-etsi-bounces at lists.fiware.org<mailto:fiware-oasc-etsi-bounces at lists.fiware.org> [mailto:fiware-oasc-etsi-bounces at lists.fiware.org] On Behalf Of gilles.privat at orange.com<mailto:gilles.privat at orange.com>
Sent: Tuesday, January 12, 2016 12:53 PM
To: Tobias Jacobs; RAMPARANY Fano IMT/OLPS; fiware-iot at lists.fiware.org<mailto:fiware-iot at lists.fiware.org>; EXCOFFIER David IMT/OLPS; Toni Alatalo; Fiware-oasc-etsi at lists.fiware.org<mailto:Fiware-oasc-etsi at lists.fiware.org>; fiware-ngsi at lists.fiware.org<mailto:fiware-ngsi at lists.fiware.org>; MARTIGNE Patricia IMT/OLN; fiware-chapter-architects at lists.fiware.org<mailto:fiware-chapter-architects at lists.fiware.org>
Subject: Re: [Fiware-oasc-etsi] [Fiware-ngsi] Preliminary proposal for evolution of FIWARE APIs and data models, based on JSON-LD --->version on a google docs document
Hello
Some further comments on the remarks by Tobias
· Using dereferenceable URIs in the linked data approach is exactly the opposite of storing information in a single point : typically pieces of ontologies can be used that are stored for reference anywhere (e.g. on standard’s organization site, a vendor’s site, an industry forum’s site). However a representation associated to the corresponding resource should be retrievable through web protocols ( HTTP or CoAP), which means URNs such as ISBN should not be used in linked data
· Keeping the API as simple as possible should definitely be our aim, and this is what the pure REST architectural style requires to avoid coupling and brittleness : nothing can be simpler than a “follow your nose” API that requires no prior knowledge from client applications about an implicit or explicit data model, but this requires providing explicit links in the payload of responses that the application can follow
o We can actually make the API simpler that it is now by removing the attributes and metadata layers (see our document)
o We could use RDF-style(SPARQL) queries from a specific entry point (such as the IoTdiscovery enabler affords now) by exploiting the RDF graph underlying JSON-LD, but this would by no means be the default API
I have put online a google docs version of the document I circulated in December so that anyone can comment on it. If you make edits, please do so in change track mode (use “suggest edits” from the contextual menu activated by a right click)
https://docs.google.com/document/d/1wvNdmTEPs2lG5K74SyJhmk2WAfjS6mRzkmeX2Ci6oSk/edit?usp=sharing
De : Tobias Jacobs [mailto:Tobias.Jacobs at neclab.eu]
Envoyé : mardi 12 janvier 2016 09:16
À : Toni Alatalo
Cc : PRIVAT Gilles IMT/OLPS; RAMPARANY Fano IMT/OLPS; fiware-iot at lists.fiware.org<mailto:fiware-iot at lists.fiware.org>; EXCOFFIER David IMT/OLPS; Fiware-oasc-etsi at lists.fiware.org<mailto:Fiware-oasc-etsi at lists.fiware.org>; fiware-ngsi at lists.fiware.org<mailto:fiware-ngsi at lists.fiware.org>; MARTIGNE Patricia IMT/OLN; fiware-chapter-architects at lists.fiware.org<mailto:fiware-chapter-architects at lists.fiware.org>
Objet : RE: [Fiware-ngsi] Preliminary proposal for evolution of FIWARE APIs and data models, based on JSON-LD
Hi Toni,
Thanks for the clarification; this is also my understanding.
In the proposal document by Gilles, as far as I understood it, it was however proposed that entity id UIRs should be dereferencable, this is why I made this remark.
Best
Tobias
From: toni.alatalo at gmail.com<mailto:toni.alatalo at gmail.com> [mailto:toni.alatalo at gmail.com] On Behalf Of Toni Alatalo
Sent: Montag, 11. Januar 2016 18:43
To: Tobias Jacobs
Cc: gilles.privat at orange.com<mailto:gilles.privat at orange.com>; RAMPARANY Fano IMT/OLPS; fiware-iot at lists.fiware.org<mailto:fiware-iot at lists.fiware.org>; EXCOFFIER David IMT/OLPS; Fiware-oasc-etsi at lists.fiware.org<mailto:Fiware-oasc-etsi at lists.fiware.org>; fiware-ngsi at lists.fiware.org<mailto:fiware-ngsi at lists.fiware.org>; MARTIGNE Patricia IMT/OLN; fiware-chapter-architects at lists.fiware.org<mailto:fiware-chapter-architects at lists.fiware.org>
Subject: Re: [Fiware-ngsi] Preliminary proposal for evolution of FIWARE APIs and data models, based on JSON-LD
Do note that URIs do *not* actually "mean that all information about an entity would be stored at some single location"
because URNs (names) can be and usually are location independent. only URLs are more location specific (though with how DNS works not always very much so).
For example this URI of a book is not location dependent and is always dereferencable as long we have libraries and others systems for book lookups:
urn:isbn:0451450523
(example from https://en.wikipedia.org/wiki/Uniform_Resource_Name)
~Toni
On Mon, Jan 11, 2016 at 6:17 PM, Tobias Jacobs <Tobias.Jacobs at neclab.eu<mailto:Tobias.Jacobs at neclab.eu>> wrote:
Dear Gilles,
I managed to catch Martin today for a discussion about your JSON-LD proposal before he leaves for another long series of business trips…
I try to summarize:
- we believe that JSON-LD as the data format for NGSI is useful, because
o it enables the definition of type hierarchies by means of OWL/RDF-S ontologies
o it improves the interplay of NGSI-based systems with semantics enablers, because no external ‘mapping’ from NGSI data to RDF is needed (as the data is essentially already RDF).
o Last but not least it is pretty much backwards-compatible as you already mentioned, because the additional syntax can be hidden in an @context.
- While your proposal is mainly about the data format of NGSI, we have to be very clear about what API we are talking about. NGSI in its current form has a rather limited query expressiveness – you can query for entity IDs, entity types, or use scopes to restrict the reach of your queries. This was a conscious design decision in order to enable the efficient execution of queries across distributed and federated systems. For NEC it is essential to preserve this property; so even if JSON-LD is used as the representation format of NGSI in the future, this does not mean that NGSI should support queries that require RDF graph traversals, joins, or other involved operations.
- While the usage of URIs as entity IDs is surely useful, we cannot demand them to be always dereferencable, because that would mean that all information about an entity would be stored at some single location, again contradicting NGSI’s intended support for federated systems where different aspects about an entity can be maintained by different providers.
In other words, getting information about an entity still requires an NGSI API call, not just a URL lookup.
- Also uniqueness of entity IDs we cannot be always demanded. But I think it is facilitated by JSON-LD because the @context can define custom default vocabularies for domains.
One comment of the example from your proposal where associations were used: Actually associations are not part of entity metadata, but are part of registration metadata. So a context registration can contain information about how entities and attributes are mapped to each others. Still putting this in registration metadata is to some extent a workaround, and a dedicated structure in context registrations could be more understandable.
Please let us know your opinion.
Best regards
Tobias
From: gilles.privat at orange.com<mailto:gilles.privat at orange.com> [mailto:gilles.privat at orange.com<mailto:gilles.privat at orange.com>]
Sent: Donnerstag, 7. Januar 2016 18:16
To: RAMPARANY Fano IMT/OLPS; Tobias Jacobs
Cc: fiware-ngsi at lists.fiware.org<mailto:fiware-ngsi at lists.fiware.org>; fiware-iot at lists.fiware.org<mailto:fiware-iot at lists.fiware.org>; fiware-chapter-architects at lists.fiware.org<mailto:fiware-chapter-architects at lists.fiware.org>; Fiware-oasc-etsi at lists.fiware.org<mailto:Fiware-oasc-etsi at lists.fiware.org>; MARTIGNE Patricia IMT/OLN; EXCOFFIER David IMT/OLPS
Subject: RE: Preliminary proposal for evolution of FIWARE APIs and data models, based on JSON-LD
I think the key issue is the separation of the data models from the API, and this is precisely what the use of JSON-LD affords
JSON-LD does not make it possible to define the type of constraints that Tobias mentions, as an XML schema or a regular programming language would , but this is precisely what has to be defined in a more evolvable and extensible way by combining different ontologies, separately from the API, referencing them properly through relevant @type keywords
As has been proposed by Juanjo for ETSI standardization, there should be two levels of data models that can be defined separately by different ontologies :
1. A cross-domain data model redefining the NGSI data model separately from the API, along the lines of what Martin and NEC had proposed earlier : this should be aligned with the OneM2M base ontology as much as relevant (the thing/device distinction is already OK, I am not so sure about the rest… )
This data model/ontology could e.g. make it possible to specify that an entity is associated with devices that serve as sensors or actuators for it , that it has a state with continuous-valued or discrete-valued dimensions, etc…
2. Domain-specific data models , the smart city domain being the first target , but this will have to come after the definition of the cross-domain data model anyway : this could more or less be correspond to what SAREF has done for smart appliances (which gives an idea of the magnitude of the task)
De : RAMPARANY Fano IMT/OLPS
Envoyé : jeudi 7 janvier 2016 17:29
À : Tobias Jacobs; PRIVAT Gilles IMT/OLPS; fiware-ngsi at lists.fiware.org<mailto:fiware-ngsi at lists.fiware.org>; fiware-iot at lists.fiware.org<mailto:fiware-iot at lists.fiware.org>; fiware-chapter-architects at lists.fiware.org<mailto:fiware-chapter-architects at lists.fiware.org>; Fiware-oasc-etsi at lists.fiware.org<mailto:Fiware-oasc-etsi at lists.fiware.org>
Cc : LI Wenbin IMT/OLPS; DANNO Vincent IMT/OLN; EXCOFFIER David IMT/OLPS; RICHARD Francois SCE/SC; MARTIGNE Patricia IMT/OLN; CHIVOT Laurent IMT TECHNO; RIGA Joel IMT/OLPS
Objet : RE: Preliminary proposal for evolution of FIWARE APIs and data models, based on JSON-LD
Dear all,
It seems to me that there are 2 separate issues here:
- the need for using ontologies
- the use of JSON-LD as a format for echanging data about any domain of application
As for the ontologies issue, I don't really understand the need for defining an ontology for the NGSI data model. NGSI is not a domain of application and NGSI should be able to contain data from any application domain. A more standard approach for me would be to define ways to refer to existing ontologies when formating NGSI messages. For example in the NGSI entity-property-value format, when expressing that "John leavesIn Paris":
- "John", "Paris" should have an URI, and be instances of classes defined in one the ontologies.
- these ontologies should be declared somewhere in the NGSI message (for example in the meta-data part) or as a preamble message.
- "leavesIn" should have an URI and be a property defined in one of the ontologies.
What worries me in your proposal when you say:
"An NGSI type ontology expresses which entity types exist in an NGSI system"
is that it seems to limit the applicability of the system. What if I'd like to tell something about an entity which type is not in the NGSI type ontology? But maybe I didn't understand your proposal correctly.
About the JSON-LD issue, I think it is a matter of taste. However, I think that this option has a better potential for adoption by web developpers over other RDF serialization languages (RDF/XML, TURTLE, RDFa, ...) because JSON is already intensively used by web applications developpers.
Best regards,
Fano
De : fiware-ngsi-bounces at lists.fiware.org<mailto:fiware-ngsi-bounces at lists.fiware.org> [mailto:fiware-ngsi-bounces at lists.fiware.org] De la part de Tobias Jacobs
Envoyé : jeudi 7 janvier 2016 11:23
À : PRIVAT Gilles IMT/OLPS; fiware-ngsi at lists.fiware.org<mailto:fiware-ngsi at lists.fiware.org>; fiware-iot at lists.fiware.org<mailto:fiware-iot at lists.fiware.org>; fiware-chapter-architects at lists.fiware.org<mailto:fiware-chapter-architects at lists.fiware.org>; Fiware-oasc-etsi at lists.fiware.org<mailto:Fiware-oasc-etsi at lists.fiware.org>
Cc : LI Wenbin IMT/OLPS; DANNO Vincent IMT/OLN; EXCOFFIER David IMT/OLPS; RICHARD Francois SCE/SC; MARTIGNE Patricia IMT/OLN; CHIVOT Laurent IMT TECHNO; RIGA Joel IMT/OLPS
Objet : Re: [Fiware-ngsi] Preliminary proposal for evolution of FIWARE APIs and data models, based on JSON-LD
Hi Gilles,
I have read your proposal on using JSON-LD and I think I have more or less understood it, but I need to discuss with some of my colleagues, who are currently out.
Anyway, my main question is currently how JSON-LD can help to solve the requirement on entity type systems Martin and me have formulated here: https://github.com/telefonicaid/fiware-orion/issues/1516
“
NEC proposes to include in the NGSI 2 specs syntax and semantics for NGSI type ontologies.
An NGSI type ontology expresses
Which entity types exist in an NGSI system
Which value types are used by an NGSI system
Which metadata names are used in an NGSI system
Relations:
o Which entity types have which attributes, and what are the value types of these attributes
o Which entity types are related by a subtype-relationship. Entity Subtypes inherit all attributes from their supertypes
o Which metadata names have which metadata types
o (maybe) which value types can have which metadata
This kind of information can be expressed by an ontology. What we propose is to
Define an ontology structure, i.e. specify how the above information is to be expressed
Define a lightweight NGSI base ontology containing o Only the entity type “entity” which is the supertype of all other entities o Basic value types for string, numbers, dates/time, maybe geo-location o Basic metadata like timestamp, accuracy, provider o Basic attributes of entity type “entity” for describing e.g. the entity location
A concrete NGSI system deployment can then extend the base ontology with all the entities/attributes/metadata used within the system. By publishing that ontology, users then know which entity types they can query.
“
If entities are represented as RDF nodes (or, in JSON-LD terms, as JSON objects with an IRI as @id), then of course it is natural to use the @type as a reference to an RDF node representing the entity type. But this does not yet give information about which attributes (JSON-LD: properties) an entity of a specific type can have, what are the value types of these attributes, and what is the supertype of a specific entity type.
As far as I understand in JSON-LD the @type for nodes is nothing more than a predefined link label.
Then there is also the possibility to use @context objects to describe the attributes (properties) of an entity (node). But the @type property does not link to an @context object but to a node.
Maybe there is a standardized way to represent type hierarchies in RDF, which we can re-use?
Best
Tobias
From: fiware-iot-bounces at lists.fiware.org<mailto:fiware-iot-bounces at lists.fiware.org> [mailto:fiware-iot-bounces at lists.fiware.org] On Behalf Of gilles.privat at orange.com<mailto:gilles.privat at orange.com>
Sent: Donnerstag, 31. Dezember 2015 12:06
To: fiware-ngsi at lists.fiware.org<mailto:fiware-ngsi at lists.fiware.org>; fiware-iot at lists.fiware.org<mailto:fiware-iot at lists.fiware.org>; fiware-chapter-architects at lists.fiware.org<mailto:fiware-chapter-architects at lists.fiware.org>; Fiware-oasc-etsi at lists.fiware.org<mailto:Fiware-oasc-etsi at lists.fiware.org>
Cc: LI Wenbin IMT/OLPS; DANNO Vincent IMT/OLN; EXCOFFIER David IMT/OLPS; RICHARD Francois SCE/SC; MARTIGNE Patricia IMT/OLN; CHIVOT Laurent IMT TECHNO; RIGA Joel IMT/OLPS
Subject: [Fiware-iot] Preliminary proposal for evolution of FIWARE APIs and data models, based on JSON-LD
Dear colleagues
A discussion had been initiated a few months ago by Jose Manuel and Fermin on the Orion GitHub about the use of JSON-LD for the FIWARE API.
We propose to extend this discussion in view of the planned re-standardization of the FIWARE API and data model.
Attached is a draft position paper on how we could rethink the API and make it more appealing to developers, more generic and more evolvable by separating it completely from the data models, precisely by using JSON-LD.
This is just a basis for starting initiating a discussion, not a definite proposal.
Cordially
[http://www.francetelecom.com/sirius/logos_mail/orange_logo.gif]
Gilles Privat
Senior Scientist
Orange Labs, Grenoble
M2M, Internet of Things, Smart Cities
gilles.privat at orange.com<mailto:gilles.privat at orange.com>
office +33 4 38 42 86 16<tel:%2B33%204%2038%2042%2086%2016>
mobile +33 6 71 17 64 60<tel:%2B33%206%2071%2017%2064%2060>
Twitter @gilles_privat
http://research.orange.com/en/page-author/gilles-privat/
http://www.linkedin.com/in/gillesprivat
http://www.researchgate.net/profile/Gilles_Privat/
28 Chemin du Vieux Chêne
BP 98 38243 Meylan, France
_________________________________________________________________________________________________________________________
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,
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, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________
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,
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, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
Since January 1st, old domains won't be supported and messages sent to any domain different to @lists.fiware.org<http://lists.fiware.org> will be lost.
Please, send your messages using the new domain (Fiware-ngsi at lists.fiware.org<mailto:Fiware-ngsi at lists.fiware.org>) instead of the old one.
_______________________________________________
Fiware-ngsi mailing list
Fiware-ngsi at lists.fiware.org<mailto:Fiware-ngsi at lists.fiware.org>
https://lists.fiware.org/listinfo/fiware-ngsi
_________________________________________________________________________________________________________________________
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,
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, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________
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,
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, 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/20160113/7aa67c97/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 1264 bytes
Desc: image001.gif
URL: <https://lists.fiware.org/private/fiware-ngsi/attachments/20160113/7aa67c97/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 44508 bytes
Desc: image002.png
URL: <https://lists.fiware.org/private/fiware-ngsi/attachments/20160113/7aa67c97/attachment.png>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy