Re: WebID default serialization for WebID 2.x

Hello all,

> I do not understand the notion that anyone should be implementing
> their own conneg or JSON-LD parser.

Not everyone uses Java, JavaScript or any of the languages listed
at https://json-ld.org . Production-ready support for JSON-LD is not as easily
achieved outside of Java and JavaScript.

> The "no dependencies" constraint is completely self-imposed and I
> would argue at odds with general software development practices,
> especially in an enterprise setting (I've worked at SAP for 5 years).

The "no dependencies" argument, which is fortunately more nuanced than
a binary one, is definitely self-imposed and correctly so (IMHO), particularly 
when it comes to engineering software that needs to run remotely, embedded and
unsupervised, for years.

In any case, I do not want to argue in favor or against a specific approach
to software engineering but merely point out that different approaches do exist
and that a spec such as WebID should aim for the common denominator, which does
not (easily) include conneg and JSON-LD parsing.

> As such, this sort of structured representation has several advantages: it
> is easy to extend (as shown with the Solid case), it is easy to deploy as a
> static resource and (arguably) this format would be easy for constrained
> devices to consume, as was suggested in the IoT case. In fact, a client
> application would have no real need for an RDF parser at all -- it merely
> needs to read the document as JSON and verify the value(s) in the @context
> array; no full JSON-LD parser is necessary. But if a client wants all the
> semantic richness of the full RDF graph, that option is still open by using
> a JSON-LD 1.1 parser.

Very nice! Thank you Aaron for coming up with this example. Seems like a good
tradeoff, I really like the direction. I am personally in favor of Turtle as
the default and mandatory serialization format for both clients and publishers
but I'd be happy with a WebID 2.0 spec based on what you suggest.

Best regards,
Jacopo.

Received on Sunday, 23 January 2022 22:08:19 UTC