Re: Observations on WebID definition and specification

Hi Martynas,

You are right, the SPARQL specs also define a protocol. However, you fail
to address my questions: do you or do you not believe that WebID should
provide guaranteed interoperability? Because therein lies the difference
with SPARQL: WebID provides a _single_ crucial access point that
applications in the ecosystem will _need_ to access. This is a lot less
problematic for SPARQL: the same dataset might be available via other
interfaces, form other sources, and it is very use-case-dependent whether
access to that an endpoint is really necessary or not.

Best,

Wouter

PS: This actually is not about spec orthogonality. That principle is about
functional modularity. Since I argue that absolute interoperability falls
within the function of the WebID spec, and such function is not provided by
HTTP conneg, an obligatory WebID format does not go against spec
orthogonality.

On Fri, Feb 9, 2024 at 10:06 AM Martynas Jusevičius <martynas@atomgraph.com>
wrote:

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