Examine potential of SOSA and JSON-LD as normative option for JSON encoding

[rob-metalinkage]

Given :

1. SOSA is an RDF model implementing O&M,
2. and can therefore be serialised directly as JSON-LD
3. and JSON-LD is JSON

the option of using this as the canonical JSON encoding should be considered and either adopted or explicitly rejected with a detailed rationale for why this is not appropriate.

that said - there are clean and dirty ways to serialised as JSON-LD - the cleanest way is to define a context document that can be reused to bind JSON elements to SOSA URIs. The "dirty" way is to include full URIs in every element and not publish a reusable context at all.

The decision would be whether to assume a default namespace or make sosa explicit:

"featureOfInterest" vs "sosa:featureOfInterest"

(this means either mapping featureOfInterest or just the sosa: namespace to the SOSA equivalent)

[akuckartz]

See also w3c/sdw#8

[sgrellet]

Indeed, these are topics we raised in the SWG meetings (and also in OGC SELFIE).
So far, we try to respect the timeline (O&M Conceptual Model 1st).

One quick note, there are changes in the conceptual model that will need be "propagated/discussed" before this could happen.
I haven't had time to generate the corresponding issues in SOSA GitHub.

And 'in the other direction', there are aspects from current version of SOSA that are already being included into O&M V3 conceptual model

[dr-shorthair]

I have propagated a few issues triggered by discussions here:

• Change prefLabel of sosa:Sensor to 'Observer' w3c/sdw-sosa-ssn#29
• Allow hasResult on ObservationCollection w3c/sdw-sosa-ssn#28
• Relax cardinality of hasUltimateFeatureOfInterest on ObservationCollection w3c/sdw-sosa-ssn#27

[KathiSchleidt]

To my view, one of the real issues here is how to bridge the (Geo)JSON(-LD) divide, fine for points, impossible for everything else...
IMHO - we could just nail this with a sort of good practice, for all geos beyond point the GeoJSON just provides a representative point, true geometry is then provided somewhere in the properties, e.g. the geosparql approach proposed by (S)ELFIE

[cportele]

@KathiSchleidt - No longer an issue with JSON-LD 1.1 (e.g., https://www.w3.org/TR/json-ld/#example-84-coordinates-expressed-in-json-ld).

[KathiSchleidt]

@cportele Cool! thanks for this pointer! @list was the missing link :)
And, as its coming from you, I'm fairly sure that all the tricky GeoBits are now covered

[sgrellet]

See also #32

[KathiSchleidt]

As I'm struggling to understand the ramifications of including -LD to the GeoJSON mix, think we really need examples!
To what extent would supporting -LD only require providing the necessary links for the context block, to what extent does it influence our internal encoding?
My request to all - if you have any valid examples, please share here so we can compare and learn!

[rob-metalinkage]

Any updates on this? the examples at https://github.com/opengeospatial/om-swg/wiki/OM-JSON-Ideas reference context documents that dont resolve - does that mean a normative context document doesnt exist or these links are stale?

FYI I am working on the HY_Features model and looking to provision JSON-LD contexts normatively. As a potential "Feature Of Interest" model for O&M would really like to establish compatibility of approach.

• at this stage I still don't see we have a mature JSON-schema option, but guess we'll have to have a go with emerging FG-JSON as a baseline. Since HY_Features has explicit "hydrological topology" the absence of geometric topology support wont be a show stopper, but the absence of a canonical JSON-LD context would need to be addressed there too..

[KathiSchleidt]

The OMS page you reference was more of a hackathon (encodathon?), first quick sketches.
We've done a bit more on LDing STA, still thought in progress, but most context links resolve (but do sometimes have issues, partially discussed in the thread):
opengeospatial/sensorthings#137