Re: Observations on WebID definition and specification

Hi Wouter,

My quick response.

The specification orthogonality principle still applies whether it is
a protocol specification or not.

Clearly not every syntax will speak every RDF syntax, but that is what
standard HTTP content negotiation was designed for.

And lastly, lets look at the SPARQL 1.1 Protocol which clearly also is
a protocol:
https://www.w3.org/TR/sparql11-protocol/#query-success

"The response body of a successful query operation with a 2XX response
is either:
* a SPARQL Results Document in XML, JSON, or CSV/TSV format (for
SPARQL Query forms SELECT and ASK); or,
* an RDF graph [RDF-CONCEPTS] serialized, for example, in the RDF/XML
syntax [RDF-XML], or an equivalent RDF graph serialization, for SPARQL
Query forms DESCRIBE and CONSTRUCT)."

For RDF graphs, not mandated serialization, just an example.

Best,

Martynas

On Fri, Feb 9, 2024 at 11:59 AM Wouter Termont <woutermont@gmail.com> wrote:
>
> 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.
>> >
>>

Received on Friday, 9 February 2024 09:06:52 UTC