Re: WebID default serialization for WebID 2.x

On Sun, 23 Jan 2022 at 13:40, 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.
>

Good point.  I think we have at least 3 people in the group that want to
work on that use case.

This could perhaps warrant its own thread.


>
> Best regards,
> Jacopo.
>
>
>
>
>
>
>
>
>