Re: [core] Designs to resolve streaming issues in SenML

[Christian Amsüss <[e-mail]>]

On Mon, Jan 18, 2016 at 09:30:47AM -0800, Michael Koster wrote:
> “bn": {"@id": “some:baseURI", "@type": "@id"}
> “n": {"@id": “some:baseURI", "@type": "@id”}

I think that this is one point where any of the existing SenML drafts
fail to produce meaningful statements for arbitrary SenML documents;
with a context as sketched above, the bn would be ignored completely,
and the value of the event's n would be a concatenation of the document
URI and the n.

After processing this into RDF, there wouldn't even be enough
information left to post-process bn into the names even if that were
somehow more practical than pre-processing the JSON.

Unless we go full JSON-LD by changing "bn" into "@base" in some way, or
JSON-LD is extended to allow something like {"@base":{"@query":
"[0].bn"}} (like xpath for json, no idea if something exists or is
feasible), I don't see how we can have the semantics of SenML
transformed into RDF by JSON-LD.

We could probably describe a subset of SenML that works for a specific
context (for example by completely ruling out bn), but how useful would
that be out in the wild?

(Similar issues exist with the whitespace separated fields in the rt
field in link-format. draft-ietf-core-links-json-04 mentions JSON-LD,
but at the same time makes "[n]o attempt [...] to decode the possibly
space-separated values for rt=" -- as long as neither links-json nor
JSON-LD deals with string splitting, we can't have JSON-LD parsing for
generic link-format).


To compare this to RDFa which could probably work with the XML
serialization as JSON-LD could work with the JSON one: To have support
for the HTML base element, RDFa had to specify (X)HTML+RDFa as a "host
language" to cover the base tag -- which basically means that whatever
processes HTML+RDFa needs to do preprocessing.

Unless those issues can be managed in any way, I don't see much point in
engineering the SenML standard towards JSON-LD convertibility. How do
you overcome them in your own applications?

Best regards
Christian

-- 
Christian Amsüss                      | Energy Harvesting Solutions GmbH
founder, system architect             | headquarter:
mailto:[e-mail]  | Arbeitergasse 15, A-4400 Steyr
tel:[phone]                | http://www.energyharvesting.at/
                                      | ATU68476614