Re: WebID default serialization for WebID 2.x

I do not understand the notion that anyone should be implementing
their own conneg or JSON-LD parser. I have implemented neither of
these things and our servers support both, because we combined JAX-RS
and Jena frameworks which provide respective implementations out of
the box.

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).

On Sun, Jan 23, 2022 at 1:40 PM Jacopo Scazzosi <jacopo@scazzosi.com> wrote:
>
>
> 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:55:54 UTC