Re: Profiles in Linked Data

Lars,

I am not convinced your use case requires a whole new concept (and
following implementations) of "Linked Data profiles".

I have outlined practical solutions you already can use now:
1. use a single description including all vocabularies
2. make separate resources with separate descriptions
3. give the client SPARQL access

It seems to me that you have a hypothetical solution and are looking
for a problem.

On Thu, May 7, 2015 at 3:24 PM, Svensson, Lars <L.Svensson@dnb.de> wrote:
>> 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 14:26:36 UTC