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] On Behalf Of Toni Alatalo
Sent: Montag, 11. Januar 2016 18:43
To: Tobias Jacobs
Cc: gilles.privat at orange.com; RAMPARANY Fano IMT/OLPS; fiware-iot at lists.fiware.org; EXCOFFIER David IMT/OLPS; Fiware-oasc-etsi at lists.fiware.org; fiware-ngsi at lists.fiware.org; MARTIGNE Patricia IMT/OLN; 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/fiware-oasc-etsi/attachments/20160112/fd659cad/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-oasc-etsi/attachments/20160112/fd659cad/attachment.gif>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy