- From: Svensson, Lars <L.Svensson@dnb.de>
- Date: Thu, 7 May 2015 11:34:44 +0000
- To: Martynas Jusevičius <martynas@graphity.org>
- Cc: "public-lod@w3.org" <public-lod@w3.org>
Martynas, > As you wrote, media type is orthogonal to profiles. To retrieve > RDF/XML, you would use content negotiation (Accept header). > > You would need to run the Graphity processor that would match URI > templates and execute SPARQL queries from the sitemap ontology. > > Sure, instead of query strings OK. But that would require the client to re-write the resource URI to put in the correct query string. > you could use Accept-Profile/Profile or > similar headers to advertise profiles and their preference. It's just > that the uptake for new custom HTTP headers will be slow, so there's > not much practical advantage. > > On the other hand, it seems like you want different descriptions of a > resource -- so it seems to me that these should in fact be different > resources? That could be split into > http://example.org/some/resource/dcat and > http://example.org/some/resource/premis, for example. Well, at least to me it is two descriptions of the same resource (much as a mobile-optimised website is the same resource as the "real" website, but sort of minimalised). Particularly when I refer to concepts, e. g. "Semantic Web" [1], or persons, e. g. "Tim Berners-Lee" [2], the URI references the RWO in no particular format. When I client actually wants to _do_ something with that information, the client and the server need to negotiate a way to find the best description. That is where profiles (or shapes) enter the equation. [1] http://d-nb.info/gnd/4688372-1 [2] http://d-nb.info/gnd/121649091 Best, Lars
Received on Thursday, 7 May 2015 11:35:13 UTC