Re: WebID default serialization for WebID 2.x

Jacopo,

So essentially because of limitations of your programming
platform/language, you want to take a protocol that follows the
architecture of the WWW and implements content negotiation, and change
it to contain the anti-pattern of canonical representation, which will
impact all implementations across the board.

Am I getting this right?

Martynas

On Sun, Jan 23, 2022 at 11:08 PM Jacopo Scazzosi <jacopo@scazzosi.com> wrote:
>
>
> 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 Monday, 24 January 2022 10:30:21 UTC