[Fiware-oasc-etsi] Preliminary proposal for evolution of FIWARE APIs and data models, based on JSON-LD

[fano.ramparany at orange.com]

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] De la part de Tobias Jacobs
Envoyé : jeudi 7 janvier 2016 11:23
À : PRIVAT Gilles IMT/OLPS; fiware-ngsi at lists.fiware.org; fiware-iot at lists.fiware.org; fiware-chapter-architects at lists.fiware.org; 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
mobile +33 6 71 17 64 60
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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/fiware-oasc-etsi/attachments/20160107/ace84cc7/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/20160107/ace84cc7/attachment.gif>