Re: WebID and Content Negotiation

> On 27. Jan 2022, at 19:51, Martynas Jusevičius <martynas@atomgraph.com> wrote:
> 
> On Thu, Jan 27, 2022 at 7:19 PM Jacopo Scazzosi <jacopo@scazzosi.com> wrote:
>> 
>> Hi all,
>> 
>>> Could we come to a consensus that content negotiation is optional for
>>> current and future WebID work?
>> 
>> I agree that it should remain optional, as per the current WebID spec/draft:
>> 
>> a) conneg tends to be incompatible with hosting of static resources
>> b) conneg comes with its own complexity, which should not be forced upon
>>   adopters of the spec

Content-negotiation works with static resources too. 

You can have 1 static resource served with 1 mime type and a client can content negotiate
in order to receive that mime-type, or you can have multiple ones.
There is documentation on the W3C Web site to help with how to set that up with Apache.
https://www.w3.org/TR/swbp-vocab-pub/

I serve my WebID profile following that in
Turtle, N3, NTriples and RDF/XML.

https://bblfish.net/people/henry/card#me

But I could also just have published Turtle if I wanted to.

>> 
>> In practice, this entails that a client asking for a specific serialization
>> format might:
>> 
>> - receive a response in the requested format
>> - receive a "406 Not Acceptable" response if the requested format is not
>>  supported by the publisher but basic conneg is
>> - receive the response in a different format if the publisher does not support
>>  conneg
>> 
>> I'm happy with all three implications.
> 
> I think at this point we need to put the prose behind us and make HTTP
> request/response examples for each use case, in order to remove any
> ambiguity. Request examples:
> 
> 1. No format preference (canonical format is Turtle)
> 
> GET /webid
> 
> 2. Canonical format (Turtle) is preferred
> 
> GET /webid
> Accept: text/turtle, application/rdf+xml;q=0.8
> 
> 3. Non-canonical RDF format is preferred and supported by the server
> 
> GET /webid
> Accept: application/rdf+xml, text/turtle;q=0.8
> 
> 4. Non-canonical RDF format is preferred and *not* supported by the server
> a. without fallback
> 
> GET /webid
> Accept: application/rdf+xml
> 
> b. with Turtle as fallback
> 
> GET /webid
> Accept: application/rdf+xml, text/turtle;q=0.8
> 
> 5. HTML is preferred and supported by the server
> 
> GET /webid
> Accept: text/html, text/turtle;q=0.8
> 
> 6. HTML is preferred and *not* supported by the server
> a. without fallback
> 
> GET /webid
> Accept: text/html
> 
> b. with Turtle as fallback
> 
> GET /webid
> Accept: text/html, text/turtle;q=0.8

Thanks Martynas Jusevičius, that is a good summary.

The spec just tells us what the mime type by default is, so that
client writers can have some idea of the minimal requirements they
need to satisfy for interoperability.

Without the default, clients would need to have 10 parsers around, 
and it actually keeps growing now with RDF* for example recently, N3 soon,
We may then even want clients to take GRDDl into account.
Here are just the RDF mime types I have registered for my server
https://github.com/co-operating-systems/Reactive-SoLiD/blob/master/src/main/scala/run/cosy/http/RDFMediaTypes.scala

I am in favor of having clients support many formats. For example
this is what my server (when working as a client) uses when making 
requests at present
https://github.com/co-operating-systems/Reactive-SoLiD/blob/master/src/main/scala/run/cosy/http/RdfParser.scala#L33

But if we want people to be able to join the community easily, we can’t
just before they even get going ask them to write 20 parsers for the
same data structure. I think it is obvious how that would put people off.

I actually wrote up a little table in August showing how defaults on
the server translate to requirements on the client

https://github.com/w3c/WebID/issues/3#issuecomment-898951657

Since we already have so many deployed WebIDs and it is 
central to the Work on Solid, I think that we would need
to do some empirical work to find out what the options are
for a way forward.

I think we should be guided by interoperability needs of applications
that have real momentum. Otherwise this could well be a ”number of
angels that can fit on a pinhead” type discussion.

Henry

> 
>> 
>> Best regards,
>> Jacopo.
>> 
>> 
>

Received on Friday, 28 January 2022 07:56:08 UTC