- From: Tim Berners-Lee <timbl@w3.org>
- Date: Mon, 13 Feb 2017 08:48:59 +0000
- To: Martynas Jusevičius <martynas@graphity.org>
- Cc: Ruben Verborgh <Ruben.Verborgh@ugent.be>, public-lod <public-lod@w3.org>, "public-rww@w3.org" <public-rww@w3.org>
> On 2017-02 -09, at 19:33, Martynas Jusevičius <martynas@graphity.org> wrote: > > The issue is not with RDF or resource identification though. Even only > considering image media types, such browser behavior breaks > applications. > > If for example both image/svg and image/png are supported, and maybe > SVG is preferred, the server cannot make an informed choice based on > Accept: */* only. What is the problem? The client has said “I will understand all formats perfectly”. (on in this case for the client Qsvg = Qpng = 1.0) That is what */* means. Now the server already has preferences. Suppose the original image was an SVG image, and the PNG was a bitmap rendering. The SVG image is better because for example: - It is the exact image, and perfect - the PNG is an approximation which assumed a particular screen size - The SVG is editable, so the client can edit it and replace it So the conversion to PNG has lost quality, and editability. So the server may be set up with its internal quality levels as Qsvg = 1.0 Qpng = 0.5 The server takes its own numbers and multiplies by the clients numbers for each content type and takes the highest. The clients are are both 1.0, so the SVG gets 1.0 and the PNG 0.5, so it returns the SVG. If the client in fact lied and cannot understand the SVG, then it loses, but that is not your fault! > > The bug I linked to describes a real-world example, though even before > Firefox switched to */*: > https://bugzilla.mozilla.org/show_bug.cgi?id=1249474 > > On Thu, Feb 9, 2017 at 8:23 PM, Ruben Verborgh <Ruben.Verborgh@ugent.be> wrote: >>> and dct:format adds >>> support for some extra media types. >> >> That's not the definition of dct:format. >> It's meaning is not "is available as" but rather >> "The file format, physical medium, or dimensions of the resource." >> >> Which sources do you find for your definition? >> >>> So a more explicit (but not practical) example would be something like: >>> >>> <http://some.com/img/19f87c54-bb97-4aa7-8163-166e3858f45e> >>> dct:format "image/jpeg", "application/xhtml+xml", >>> "application/rdf+xml", "application/n-quads", "text/rdf+n3", >>> "application/n-triples", "application/ld+json", "application/rdf+xml", >>> "application/rdf+thrift", "text/turtle", "text/trig" . >> >> I cannot think of any resource that can be both represented >> as application/n-triples and image/jpeg, >> unless that image/jpeg is a "screenshot" of the text or something >> (but let's agree that is a pathological case). >> >> In the more general case, no JPEG image can be represented as RDF; >> rather, a document about that image can be represented as RDF. >> So we are talking about two different resources: >> – the image (can have representations: JPEG, GIF, PNG, …) >> – metadata about the image (can have representations: HTML, Turtle, …) >> >> In other words, the resource design as presented is wrong; >> two different things are being conflated into one. >> >>> Do your arguments still hold? >> >> Yes. >> >> Best, >> >> Ruben > >
Received on Monday, 13 February 2017 08:49:12 UTC