- From: Martynas Jusevičius <martynas@graphity.org>
- Date: Thu, 9 Feb 2017 20:06:13 +0100
- To: Ruben Verborgh <Ruben.Verborgh@ugent.be>
- Cc: public-lod <public-lod@w3.org>, "public-rww@w3.org" <public-rww@w3.org>
Ruben, why are you inferring the format from the URI? The URIs are opaque; only RDF specifies the format here. Let me improve the example -- no filename extension, just some document URI: <http://some.com/img/19f87c54-bb97-4aa7-8163-166e3858f45e> dct:format "image/jpeg" . It identifies a resource which may have multiple representations: JPEG, RDF, HTML etc. The representations could be standalone resources, but they don't need to. On Thu, Feb 9, 2017 at 7:59 PM, Ruben Verborgh <Ruben.Verborgh@ugent.be> wrote: > Hi Martynas, > >> <http://some.com/img/abc.jpg> dct:format "image/jpeg" . > > So this URI points to a specific representation of the ABC image, > namely a JPEG version of it. > >> This allows my Linked Data >> platform to respond in at least 3 different ways to a request to such >> URI, depending on the Accept request header: > > No, I don't think so. > >> 1. the JPEG image for image/* > > Correct. > >> 2. the RDF metadata for any RDF syntax > > No, that's another document; > the image is different from the document describing it. > >> 3. HTML rendering of the metadata for text/html > > Idem. > >> Yet recently I noticed that some browsers started sending Accept: */* >> instead of image-specific media types: > > And that's not a problem. > With the triple above, you have defined the thing > as a JPEG representation of something. > So it can only be JPEG. > >> This provides no information for the content negotiation algorithm and >> leading to a random response format. > > It will be JPEG. > >> Anyone else thinks such behavior breaks WWW architecture? > > Not me. > >> Browser >> vendors apparently have decided that conneg is bad: >> https://wiki.whatwg.org/wiki/Why_not_conneg > > That's a rather unfortunate one-sided argument. > The reasoning is not sound in various places. > > Best, > > Ruben
Received on Thursday, 9 February 2017 19:06:46 UTC