W3C home > Mailing lists > Public > public-rww@w3.org > March 2017

Re: Browsers breaking content negotiation

From: Magnus Knuth <magnus.knuth@hpi.uni-potsdam.de>
Date: Wed, 15 Mar 2017 15:09:27 +0100
CC: Martynas Jusevičius <martynas@graphity.org>, public-lod <public-lod@w3.org>, "public-rww@w3.org" <public-rww@w3.org>
Message-ID: <4EBED18E-FECA-4C09-918B-1F2BCF82354F@hpi.uni-potsdam.de>
To: Ruben Verborgh <ruben.verborgh@ugent.be>

> Am 09.02.2017 um 20:23 schrieb Ruben Verborgh <ruben.verborgh@ugent.be>:
>> 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).

Hi Ruben,

you could represent the metadata and the content description of the media file in a machine understandable way in form of RDF. We proposed to do exactly that by using content negotiation.
A number of use cases are listed in [https://hpi.de/fileadmin/user_upload/fachgebiete/meinel/Semantic-Technologies/paper/2016Knuth-ICWE2016.pdf] ;-)

Nevertheless, it should be clear that a server must deliver the standard document when content negotiation is set to */*. Only in cases where the client asks explicitly for an RDF format, it should redirect the client to the respective RDF description of the file, which in case of a 303 see other redirect has its own URI.

Hence, I don’t see a problem in browsers accepting any format. Clients that are interested in RDF representations should set the accept header respectively.

> 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

Magnus Knuth

Hasso-Plattner-Institut für Softwaresystemtechnik GmbH
Prof.-Dr.-Helmert-Str. 2-3
14482 Potsdam

Amtsgericht Potsdam, HRB 12184
Geschäftsführung: Prof. Dr. Christoph Meinel

tel:     +49 331 5509 547
email:   magnus.knuth@hpi.de
web:     http://www.hpi.de/
webID:   http://magnus.13mm.de/
Received on Wednesday, 15 March 2017 14:09:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:10:59 UTC