Re: Observations on WebID definition and specification

Dear Martynass,

I've waited for a while to see how the conversation would develop, but I
believe your question to Jacopo summarizes the issue succinctly, and thus
warrants attention. To answer it from my perspective:

> What makes the WebID specification so special that it requires a media
type treatment which is completely at odds with all existing RDF
specifications?

There is a huge difference. The WebID specification defines a _protocol_,
while the RDF specifications (by which I understand you to mean the set of
RDF 1.x documents) define multiple _languages_. The same goes for SPARQL
and ShaCL, they're languages. Protocols, on the other hand, depend on
specific languages in order to make two product classes communicate with
each other. Without a decision on the language, communication cannot
happen.

To correct your comparison: asking WebID to be independent of syntax is
like asking HTTP to be independent of syntax, demanding it to communicate
messages in JSON, YAML, INI, or whatever other language you could possibly
express a message body and headers in. Luckily, the designers of HTTP knew
that the more syntaxes you allow, the heavier the burden on client and/or
server. Thus they designed one single syntax for HTTP messages.

Note that even abolishing a dependency on specific concrete RDF syntaxes is
a choice for a language, namely the combination of all RDF syntaxes. That
means that every participating system that does not speak _all_ of these
syntaxes is not guaranteed to work with every other WebID system. Being a
protocol, however, like HTTP, such universal interoperability is exactly
the aim of the specification. If implemented correctly, every HTTP system
can talk with every other (that implements the same version).

Now, I see two possible rebuttals against this. First, you could argue that
each client should be able to parse every existing RDF syntax. Given the
immense burden this would pose on developers and maintainers, I will assume
for WebID's sake that this is not what you want. If it is, I have nothing
more to say.

Secondly, you could argue that it is not necessary for all WebID systems to
be able to act interoperably. If this is the case, we are fundamentally at
odds about the aims of the protocol we are designing. To me (and, I
daresay, a lot of others) a WebID and its WebID Document are part of the
_glue_ that is essential for our life on the Web to become truly seamless.
They form one of a very limited set of _entry hooks_ for services to
interact with our digital presence and our data. If only an arbitrary set
of services can actually work with my WebID, why would developers bother;
what's the added value over the existing fenced ecosystems? I don't see it;
and if I don't, a lot of other people won't see it either, therefore won't
decide to use WebID, thus precluding the ecosystem to grow to the capacity
it needs to be a true benefit to the Web.

If you agree with me on both points above, I believe you _must_ realize
that the WebID protocol _needs_ obligatory support for a (small) set of
concrete RDF formats on the server-side. If not, I think the WebID CG
should make an important decision about what its aims are, whether those
aims need guaranteed interoperability or not. If it turns out that the
group indeed differs on these aims, some of us might be better off
expressing their own desires in another protocol.

All the best,

Wouter Termont


On Mon, Feb 5, 2024 at 2:14 PM Martynas Jusevičius <martynas@atomgraph.com>
wrote:

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