Re: WebID default serialization for WebID 2.x

What does "Turtle required" even mean?
1. without any Accept request header, a WebID profile document MUST
always return Content-Type: text/turtle?
2. with an Accept: text/turtle request header, a WebID profile
document MUST always return Content-Type: text/turtle?

On Wed, Jan 26, 2022 at 10:04 AM Jacopo Scazzosi <jacopo@scazzosi.com> wrote:
>
>
> > 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:10:03 UTC