- From: Magnus Knuth <magnus.knuth@hpi.uni-potsdam.de>
- Date: Wed, 15 Mar 2017 15:09:27 +0100
- To: Ruben Verborgh <ruben.verborgh@ugent.be>
- CC: Martynas Jusevičius <martynas@graphity.org>, public-lod <public-lod@w3.org>, "public-rww@w3.org" <public-rww@w3.org>
> 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