Re: Observations on WebID definition and specification

Hi Melvin,

To answer your questions:

> 1. *Serialization Neutrality:* Is the concept of defining WebID in a
serialization-neutral manner something you find fundamentally unacceptable?
If so, could you share your concerns?

Yes. My concerns should have been clear from my previous message: contrary
to other specs, WebID needs to provide absolute interoperability, which can
only be achieved through obligatory formats. This is still compatible with
serialization neutrality (we could let servers provide ALL formats), but
for practical purposes a limited set of formats seems the better choice.

> 2. *Two-Step Approach:* There's been repeated discussion around a
sequential strategy where we first define WebID independently of
serialization specifics, followed by addressing serialization. Do you
acknowledge this proposed order of operations does not exclude your use
case?

It does exclude my use case. I am not planning on putting a lot of effort
into all other aspects of the spec (step 1), if in the end it is decided to
not provide sufficient interoperability (step 2). If I know the conclusions
of the serialization discussion beforehand, I could instead throw all my
weight behind another spec if needed (e.g. some DID methods, which DO
specify exact format sets).

Hope to have made myself clear on those points.

Wouter


On Fri, Feb 9, 2024 at 10:20 AM Melvin Carvalho <melvincarvalho@gmail.com>
wrote:

>
>
> pá 9. 2. 2024 v 9:59 odesílatel Wouter Termont <woutermont@gmail.com>
> napsal:
>
>> 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.
>>
>
> Hi Wouter, would appreciate your insights on a couple of points:
>
> 1. *Serialization Neutrality:* Is the concept of defining WebID in a
> serialization-neutral manner something you find fundamentally unacceptable?
> If so, could you share your concerns?
>
> 2. *Two-Step Approach:* There's been repeated discussion around a
> sequential strategy where we first define WebID independently of
> serialization specifics, followed by addressing serialization. Do you
> acknowledge this proposed order of operations does not exclude your use
> case?
>
> The essence here is not about precluding any particular approach but
> ensuring we proceed in a manner that circumvents longstanding standoffs
> tied to serialization and implementation details. Is there an aspect of
> modularly and independently defining WebID that you find objectionable?
>
>>
>>
>> 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.
>>> >
>>>
>>>