Include Device Schema #81

LeonanCarvalho · 2016-10-31T17:51:42Z

regarding to issue #76

regarding to issue FIWARE#76

jmcanterafonseca · 2016-11-03T15:23:41Z

thanks for sending this contribution, in order not to raise a maintenance issue I would prefer for the time being not adding descriptions to the schema. In the future we will do it but only when we have a tool to automatically generate documentation from schema definitions ...

what do you think?

jmcanterafonseca · 2016-11-03T15:24:24Z

Device/Device/schema.json

@@ -0,0 +1,199 @@
+{
+    "namespace": "Device",
+    "name": "Device",


this should be named 'entityType'

This change apply for both attributes or just to name attribute?
We think about a namespace to represent a category of problem domain.

For example: Thing:Device, Environment:Air:AirQualityObserved (the namespace separator ":" is just a suggestion may / or _ can be a better choice).

I would change 'namespace' by 'module' and 'name' by 'entityType'

jmcanterafonseca · 2016-11-03T15:24:44Z

Device/Device/schema.json

+        "category": {
+            "descr": "See attribute category from DeviceModel. Optional but recommended to optimize queries.",
+            "type": "TextList",
+            "allowedvalues": {


this should be allowedValues

jmcanterafonseca · 2016-11-03T15:25:33Z

Device/Device/schema.json

+        "mnc": {
+            "descr": "This property identifies the Mobile Network Code (MNC) of the network the device is attached to. The MNC is used in combination with a Mobile Country Code (MCC) (also known as a \"MCC / MNC tuple\") to uniquely identify a mobile phone operator/carrier using the GSM, CDMA, iDEN, TETRA and 3G / 4G public land mobile networks and some satellite mobile networks.",
+            "type": "Text",
+            "allowedvalues": "*"


what's the meaning of allowedvalues '*' here? If any value is allowed, then no need to say anything

Agree, if allowedValues attribute is not present any value of a given type ca be applied.

jmcanterafonseca · 2016-11-03T15:27:18Z

Device/Device/schema.json

+    "name": "Device",
+    "attributes": {
+        "id": {
+            "descr": "Unique identifier.",


in the future this should be description instead of descr

jmcanterafonseca · 2016-11-03T15:28:16Z

Device/Device/schema.json

+        },
+        "serialNumber": {
+            "descr": "The serial number assigned by the manufacturer.",
+            "type": "serialNumber",


is this wrong?

i didn't catch that, whats wrong? ☕️

jmcanterafonseca · 2016-11-03T15:29:05Z

Device/Device/schema.json

+            "descr": "The provider of the device.",
+            "type": "provider",
+            "allowedvalues": {
+                "normative": "https://schema.org/provider"


disagree here, normative references has nothing to do with allowedValues. allowedValues has to do with enumerations

I agree with that, but how do will we represent normative reference?
The machine can't use that because a normative can be any schema, documentation, RF, in any format.
But it can be used to advise to user/developer which value should be used for this attribute.
Maybe:

"provider": { "description": "The provider of the device.", "type": "provider", "normative": "https://schema.org/provider" },

jmcanterafonseca · 2016-11-03T15:29:42Z

Device/Device/schema.json

+        },
+        "refDeviceModel": {
+            "descr": "The device's model.",
+            "type": "Text",


I would prefer here to be explicit and say Reference to entity of type DeviceModel.

- allowedvalues should be allowedValues - Remove allowedvalues '*' "If any value is allowed, then no need to say anything"

jmcanterafonseca · 2016-11-11T09:05:42Z

thanks for implementing some of the changes, but as I said before, at this stage, please remove descriptions, as we don't want to have descriptions duplicated in two different files

jmcanterafonseca · 2016-12-01T17:04:26Z

Device/Device/schema.json

+        "controlledAsset": {
+            "description": "The asset(s) (building, object, etc.) controlled by the device.",
+            "type": "TextList",
+            "allowedValues": {


shouldn't we call this type "Reference" ?

jmcanterafonseca · 2016-12-01T17:05:19Z

Device/Device/schema.json

+            "description": "Location of this device represented by a GeoJSON geometry of type point.",
+            "type": "geo:json",
+            "allowedValues": {
+                "normative": "https://tools.ietf.org/html/rfc7946"


normative better as a direct child of location

jmcanterafonseca · 2016-12-01T17:05:27Z

Device/Device/schema.json

+            "description": "A mnemonic name given to the device.",
+            "type": "name",
+            "allowedValues": {
+                "normative": "https://schema.org/name"


same as above

jmcanterafonseca · 2016-12-01T17:05:34Z

Device/Device/schema.json

+            "description": "Device's description.",
+            "type": "description",
+            "allowedValues": {
+                "normative": "https://schema.org/description"


same as above

jmcanterafonseca · 2016-12-01T17:05:48Z

Device/Device/schema.json

+            "description": "The hardware version of this device.",
+            "type": "Text"
+        },
+        "hardwareVersion": {


duplicated please check and validate

jmcanterafonseca · 2016-12-01T17:05:59Z

Device/Device/schema.json

+            "description": "The serial number assigned by the manufacturer.",
+            "type": "serialNumber",
+            "allowedValues": {
+                "normative": "https://schema.org/serialNumber"


same comment as above

jmcanterafonseca · 2016-12-01T17:06:04Z

Device/Device/schema.json

+            "description": "The provider of the device.",
+            "type": "provider",
+            "allowedValues": {
+                "normative": "https://schema.org/provider"


jmcanterafonseca · 2016-12-01T17:06:17Z

Device/Device/schema.json

+        },
+        "refDeviceModel": {
+            "description": "Reference to entity of type DeviceModel.",
+            "type": "Text",


jmcanterafonseca · 2017-01-17T15:47:26Z

@LeonanCarvalho we have resumed the work on JSON Schema and today we landed infra and a JSON Schema for WeatherObserved. If you are still interested in working on this please refresh this work. Otherwise we will take your input and adapt it.

This week we plan to work on 'WeatherForecast' and 'AirQualityObserved' .

thanks!

LeonanCarvalho · 2017-01-17T16:24:58Z

@jmcanterafonseca Sorry for my delay to keep it updated.

I want to be involved in the development of this schemas, but I do not know if I can update these models as quickly as I would like. Even a bit of inexperienced with Github.

If you want to adapt it feel free to do so. I'll keep watching the repository and I will make contributions when possible.

What could I do immediately to update this work?

jmcanterafonseca · 2017-01-17T16:55:19Z

@LeonanCarvalho I would be happier if these schemas are developed by you, guys. We want to encourage community participation.

We plan to work immediately on Weather and environment schemas. As you are working on different schemas this can be compatible with your development pace. In order to land your work, please could have a look at

https://github.com/Fiware/dataModels/blob/master/Weather/WeatherObserved/schema.json

and try to align. As I said, we now focus on providing schemas and keeping doc in the md. in the future we plan to reconcile both artefacts but for the moment, it is enough with having structure and validation rules on the schemas.

please let me know

thanks!

LeonanCarvalho · 2017-01-17T17:37:15Z

@jmcanterafonseca I looked at WeatherObserved schema and It's good enough, the document is abiding by a standard, I believe that it's not difficult to consume it as proposed at #76

To involve the community, I think it will enforce a team work from @FIWARE developers (Orion Context Broker,Cygnus, Proton, etc) to consume and implement this schemas. Here have a huge list of Implementations written in different languages.

jmcanterafonseca · 2017-04-21T11:21:41Z

closing this. we will be using standard JSON Schema descriptions.

Include Device Schema

f884d3a

regarding to issue FIWARE#76

jmcanterafonseca suggested changes Nov 4, 2016

View reviewed changes

LeonanCarvalho added 2 commits November 8, 2016 09:23

Update schema.json

281b426

- allowedvalues should be allowedValues - Remove allowedvalues '*' "If any value is allowed, then no need to say anything"

Update schema.json

e7fbb56

LeonanCarvalho mentioned this pull request Nov 8, 2016

Would be nice to have a json schema for each data model #76

Closed

jmcanterafonseca suggested changes Dec 1, 2016

View reviewed changes

jmcanterafonseca closed this Apr 21, 2017

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Include Device Schema #81

Include Device Schema #81

LeonanCarvalho commented Oct 31, 2016

jmcanterafonseca commented Nov 3, 2016 •

edited

Loading

jmcanterafonseca Nov 3, 2016

LeonanCarvalho Nov 8, 2016

jmcanterafonseca Nov 11, 2016 •

edited

Loading

jmcanterafonseca Nov 3, 2016

jmcanterafonseca Nov 3, 2016

LeonanCarvalho Nov 8, 2016

jmcanterafonseca Nov 3, 2016

jmcanterafonseca Nov 3, 2016

LeonanCarvalho Nov 8, 2016

jmcanterafonseca Nov 3, 2016

LeonanCarvalho Nov 8, 2016

jmcanterafonseca Nov 3, 2016

jmcanterafonseca commented Nov 11, 2016

jmcanterafonseca Dec 1, 2016

jmcanterafonseca Dec 1, 2016

jmcanterafonseca Dec 1, 2016

jmcanterafonseca Dec 1, 2016

jmcanterafonseca Dec 1, 2016

jmcanterafonseca Dec 1, 2016

jmcanterafonseca Dec 1, 2016

jmcanterafonseca Dec 1, 2016

jmcanterafonseca commented Jan 17, 2017

LeonanCarvalho commented Jan 17, 2017

jmcanterafonseca commented Jan 17, 2017 •

edited

Loading

LeonanCarvalho commented Jan 17, 2017

jmcanterafonseca commented Apr 21, 2017

Include Device Schema #81

Include Device Schema #81

Conversation

LeonanCarvalho commented Oct 31, 2016

jmcanterafonseca commented Nov 3, 2016 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jmcanterafonseca Nov 11, 2016 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jmcanterafonseca commented Nov 11, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jmcanterafonseca commented Jan 17, 2017

LeonanCarvalho commented Jan 17, 2017

jmcanterafonseca commented Jan 17, 2017 • edited Loading

LeonanCarvalho commented Jan 17, 2017

jmcanterafonseca commented Apr 21, 2017

jmcanterafonseca commented Nov 3, 2016 •

edited

Loading

jmcanterafonseca Nov 11, 2016 •

edited

Loading

jmcanterafonseca commented Jan 17, 2017 •

edited

Loading