Re: WebID default serialization for WebID 2.x

Hi all,

> The effort to dumb down RDF Linked Data to make it more accessible to
> some mythical "developers" continues to amaze me. Those developers
> most likely do not even need Linked Data as they don't have the sort
> of problems it addresses.

I might be one of those mythical “developers”. I’m interested in WebID, 
particularly in its application within IoT and edge computing contexts.
Most of my work happens within corporate environments where inertia plays
a determinant role when it comes to embracing "new” technologies, frameworks,
approaches, paradigms.

> Top Linked Data researchers pretending not to understand content
> negotiation raises my eyebrows. It has been a feature of HTTP since
> forever.

The WebID spec should target _everyone_. Linked Data researchers are probably
invisible if we zoom out far enough to encompass all those who might get to
work with a widepsread and well-established WebID 2.0 spec.

In my opinion, any spec that aims to achieve widespread adoption must be based
upon a core set of MUSTs that a mid-senior developer should be able to easily 
implement in the few weeks (often days) that we often get to come up with
proof of concepts. Furthermore, these MUSTs should be easy to implement without
significant use of dependencies, which can be problematic in many ways,
including but not limited to licensing issues, security audits, image size.

I can get from a TCP stream to (de)serialization of Turtle or JSON HTTP 
payloads on my own, with minimal (if not zero) dependencies. However, I would
never be able to implement conneg across a number of RDF serialization formats,
particularly JSON-LD parsing, and still have the budget to work on the actual
scope of my WebID-powered PoC. In fact, JSON-LD parsing per-se (even without
conneg) might take me the entire time allocated to my PoC or the entire
allowance for additional dependencies. Of course, this doesn't apply to JSON 
payloads that also happen to be valid JSON-LD payloads due to the use of 
particular contexts.

> Without a well-defined context, however, the vagaries in 
> compact/expanded/flattened JSON-LD serializations provide a high bar for data
> parsing, and you lose a lot of the advantages that JSON-LD has to offer in the
> first place. In fact, when given the choice between Turtle (or other RDF 
> serializations) and JSON-LD without a structured context, I would always choose
> Turtle.

Fully agree.

> I think publishing a webid to a static web page is a valid use case.
> I found it quite practical, that you can just put a file on a web server
> (in this case github.io ) to serve as webid.

This is extremely important. Conneg requires a server-side component which is
not always available or, if available at all, not always easy to enable and/or
configure. Practicality of deployment should be paramount. Missing support for 
hosting of static resources would be a no-go in almost all of the environments
I work in.

Best regards,
Jacopo.

Received on Sunday, 23 January 2022 12:40:18 UTC