Re: Profiles in Linked Data

So why don't you include both DCAT and PREMIS in the description and
let the client figure it out?

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

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 11:43:03 UTC