Re: Observations on WebID definition and specification

po 5. 2. 2024 v 14:13 odesílatel Martynas Jusevičius <martynas@atomgraph.com>
napsal:

> Jacopo,
>
> Could you answer one more question: what makes the WebID specification
> so special that it requires a media type treatment which is completely
> at odds with all existing RDF specifications?
>

It's a good point, though I think LDP does mandage seralizations for
example.

Let me point out something that might be obvious or might be a gap in
understanding.

Defining and specifying webid in a serialization neutral way is the start
of the story, not the end of the story.  It's perfectly possible to take a
two-step approach of defining WebID first, and THEN, being the conversation
about seralizatoins.  The WebID definition stands on its own merits, either
way.  Modular, well-defined, loosely-coupled, extensible.


>
> Martynas
>
> On Mon, Feb 5, 2024 at 2:10 PM Jacopo Scazzosi <jacopo@scazzosi.com>
> wrote:
> >
> > Hello Martynas,
> >
> > Speaking personally and not as the chair, I think yours is an
> interesting proposal worth thinking about.
> >
> > Practically speaking, though, I’m afraid of what it implies. If I am
> right, and please correct me if I am not, having no media type requirement
> whatsoever would imply that both servers and clients would have to be
> compatible with at least the top 3 - 4 serialization formats in order for
> any WebID spec to actually achieve widespread adoption. As of today, that
> would likely be RDFa, Turtle and JSON-LD (and possibly data islands), along
> with ConNeg (and possibly signposting).
> >
> > On one side, I do agree that orthogonality would be a good thing. On the
> other side, the implications in terms of complexity are very significant,
> at least at first glance. I should note that complexity, in this case,
> primarily refers to dependencies. I don’t think anyone would spend time
> crafting new parsers from scratch.
> >
> > However... One way to frame your proposal would be in the context of the
> natural tendency of a software ecosystem to converge. In that sense, if we
> were to drop all media type requirements I would expect the ecosystem to
> quickly converge towards JSON-LD + Turtle (which is practically already the
> case) and then progress towards JSON-LD alone. Looking at it in this way, I
> would agree that yours is the best way forward.
> >
> > As chair, I’m aware of others with perfectly legitimate implementability
> concerns, which is why current consensus lies with a MUST on Turtle and
> JSON-LD. Perhaps working on examples might manage to change a few minds.
> >
> > Best,
> > Jacopo.
> >
>