You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While JSON schema is useful to validate if the JSON is of valid structure and types, JSON-LD allows one to assign semantic values to the JSON properties. This allows then even greater interoperability. I started looking into this for nodewatcher and the idea is that if we describe nodewatcher API with JSON-LD, and netjson with JSON-LD, then we get automatically convert between each other. So then our API REST endpoint can offer multiple formats, JSON (plain nodewatcher structure), JSON-LD (JSON with added JSON-LD @context attributes) and netjson (JSON-LD converted to netjson using netjson JSON-LD specification).
So, at least theoretically, this would allow us to define schemas for our APIs only once and then interchange them even if they are internally stored differently.
Because netjson is very similar to our nodewatcher API I think this could be a good proof of concept if we can get it to work.
So what we will have to do is annotate each property of netjson with its definition URI (often URI which points to https://schema.org/, or some other common schema from http://vocab.cc, http://lov.okfn.org/dataset/lov). Probably we would have to define some our own, which is also good and could be hosted at the netjson domain.
http://netjson.org/vocab for netjson specific property definitions (like routing metrics and stuff, which probably does not exist elsewhere), those same would then be used by nodewatcher JSON-LD context
http://netjson.org/contexts/v1.0/base.jsonld
So even if maybe our APIs have fields in different places inside JSON, they do share meaning of fields. (Moreover, it would be interesting to see for which fields we understand different meaning.)
Very interesting. I'm not sure I have enough time to work on this idea at this stage. There's so much work to do to write implementations: currently a good implementation for DeviceMonitoring is missing, and DeviceConfiguration has only one implementation for OpenWRT.
Plus I'm not very familiar with JSON-LD, apart from watching a few videos I did not have the time to study its specification (I took the time to read NETCONF and JSON-Schema RFC before going ahead with this work), I just added this task on my TODO list; hopefully afterwards I will be less embarrassed to discuss this.
I am just posting it here to open discussion. I am also learning about it. For nodewatcher I am hoping to be able to define everything with JSON-LD and hopefully then we could define a simple filter which would convert that into netjson automatically. But I would need netjson JSON-LD definition to know to what to convert to. So I just worry that we might discover later on that some netjson things are not easily describable in JSON-LD if we do not think about this in advance. But maybe we will be lucky. :-)
So yes, this is something long term for me as well.
While JSON schema is useful to validate if the JSON is of valid structure and types, JSON-LD allows one to assign semantic values to the JSON properties. This allows then even greater interoperability. I started looking into this for nodewatcher and the idea is that if we describe nodewatcher API with JSON-LD, and netjson with JSON-LD, then we get automatically convert between each other. So then our API REST endpoint can offer multiple formats, JSON (plain nodewatcher structure), JSON-LD (JSON with added JSON-LD
@context
attributes) and netjson (JSON-LD converted to netjson using netjson JSON-LD specification).So, at least theoretically, this would allow us to define schemas for our APIs only once and then interchange them even if they are internally stored differently.
Because netjson is very similar to our nodewatcher API I think this could be a good proof of concept if we can get it to work.
So what we will have to do is annotate each property of netjson with its definition URI (often URI which points to https://schema.org/, or some other common schema from http://vocab.cc, http://lov.okfn.org/dataset/lov). Probably we would have to define some our own, which is also good and could be hosted at the netjson domain.
See a similar attempt at GeoJSON: https://github.com/geojson/geojson-ld
And their definition of properties: http://geojson.org/vocab
And JSON-LD context: http://geojson.org/contexts/geojson-base.jsonld
We could then create:
http://netjson.org/vocab
for netjson specific property definitions (like routing metrics and stuff, which probably does not exist elsewhere), those same would then be used by nodewatcher JSON-LD contexthttp://netjson.org/contexts/v1.0/base.jsonld
So even if maybe our APIs have fields in different places inside JSON, they do share meaning of fields. (Moreover, it would be interesting to see for which fields we understand different meaning.)
cc @kostko
The text was updated successfully, but these errors were encountered: