- From: Svensson, Lars <L.Svensson@dnb.de>
- Date: Thu, 7 May 2015 13:24:38 +0000
- To: Martynas Jusevičius <martynas@graphity.org>
- Cc: "public-lod@w3.org" <public-lod@w3.org>
> So why don't you include both DCAT and PREMIS in the description and > let the client figure it out? Because that would mean that my payload would be at least twice as large (or more, depending on how many profiles I want to support). Further, a client that actually wants json but asks for json-ld (because that is the content-type the server supports) has no way to figure out which keys to evaluate and which not. Also too much information can be a constraint when we deal with clients with limited computing capabilities. Lastly I might want to specifically constrain my response to a specific profile in order to be consistent with a certain rdf shape. > I haven't yet encountered a use case where profiles would be necessary. > > WebArch only talks about representations (descriptions) that differ in > terms of media type: > http://www.w3.org/TR/webarch/#dereference-details Yes, but I still see a necessity for negotiation profiles, too, not only media types. Best, Lars > > On Thu, May 7, 2015 at 1:34 PM, Svensson, Lars <L.Svensson@dnb.de> wrote: > > 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 13:25:07 UTC