Re: WebID default serialization for WebID 2.x

> I feel something is getting lost in translation.

I have gone through quite a few message many times over and I feel the same.

I understand that there’s a difference between a URI referencing a document
that describes a WebID and the WebID itself, which is where the 303 and hash
patterns come into play.

I think I grasp the conceptual difference betweeen denotation and connotation
and how it applies to data.

However, this doesn't change the fact that I still need to dereference in order
to learn about WebIDs, which in turn does reaffirm a dependency on being able
to parse at least the serialization formats *required* by the spec and possibly
one or more of the serialization formats *suggested* by the spec. If the spec
were to stop at merely suggesting, without requiring, then clients would have 
to know how to parse all possible RDF serialization formats in order to achieve
max. compatibility.

I also understand the difference between RDF statements and their
serialization but in order to consume the former I need to predictably be able
to work with the latter.

So far I remain convinced that the current approach (Turtle required, conneg
supported but not required) stands for the best tradeoff. I am going to keep as
open a mind as I can, though.

 > You used to know it’s a WebID because we had the cert ontology that related
 > the WebID to a public Key. The core purpose of having a WebID was to tie it
 > into the WebID-TLS authentication scheme. 
> 
> For me that authentication piece has now moved over to using the IETFS [...]

This comes across as the bottom-up definition that lies at the other end of the
spectrum. Admittedly, I find this one much much easier to operate with.

Received on Wednesday, 26 January 2022 09:03:22 UTC