You’re right, RDF schema is an extension of RDF that introduce the notion of type hierarchy. OWL is itself an extension of RDF schema which introduce more notions (e.g. contraints such as cardinality on properties (relations)).
So if you’d like your system to support RDF schema (where supports means understands its constructs and process them correctly) it would be preferable that it supports OWL as well, because most people who uses RDF schema use in fact OWL.
Now if you’d like your system to handle the example you mention about “car” and “vehicle” it implies that your system should implement some form or reasoning, which implementation in my opinion is difficult and requires a very specialized skill if of course you want your system to handle this correctly. An alternative approach is to “subcontract” this reasoning to an existing reasoner.
De : Tobias Jacobs [mailto:Tobias.Jacobs at neclab.eu]
Envoyé : vendredi 8 janvier 2016 13:04
À : PRIVAT Gilles IMT/OLPS; RAMPARANY Fano IMT/OLPS
Cc : 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; MARTIGNE Patricia IMT/OLN; EXCOFFIER David IMT/OLPS
Objet : RE: Preliminary proposal for evolution of FIWARE APIs and data models, based on JSON-LD
I think I can now answer my question below by myself:
RDF can surely be used to express this kind of information (type systems) SOMEhow, but RDF as far as I understand has no built-in standard way to express type systems like this, right?
Actually there is the RDF-Schema specification http://www.w3.org/TR/rdf-schema/ which describes exactly that.
So what would be needed is to define an RDF schema for NGSI, which can then be complemented with domain-specific extensions.
Best
Tobias
From: Tobias Jacobs
Sent: Freitag, 8. Januar 2016 11:00
To: 'gilles.privat at orange.com'; RAMPARANY Fano IMT/OLPS
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
Hi all,
Thanks for your replies!
To clarify: The proposal was not to restrict the set of permitted attributes of an entity is allowed to have, but to become able to define a (generic or domain-specific) standard vocabulary for entity types, attribute names, and their value types.
For example, I would want to be able to define that
- there are two entity types “vehicle” and “car”,
- “vehicle” has an attribute “speed”,
- “car” is a subtype of “vehicle” and has an additional attribute “parking_status”.
I am looking for a standardized way to express this kind of information, so that my NGSI enabler can be queried for entities of type “vehicle” and will return also entities of type “car”.
RDF can surely be used to express this kind of information SOMEhow, but RDF as far as I understand has no built-in standard way to express type systems like this, right?
So what would be needed in my understanding is to standardize how to express type systems in RDF (using JSON-LD as the serialization format).
Does is make sense?
Best
Tobias
From: 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
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.
_________________________________________________________________________________________________________________________
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-chapter-architects/attachments/20160108/2d6203a0/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-chapter-architects/attachments/20160108/2d6203a0/attachment.gif>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy