W3C home > Mailing lists > Public > public-ldp-wg@w3.org > November 2012

Re: ldp-ISSUE-38 (filtering, inlining): filtered representations and inlining [Linked Data Platform core]

From: Roger Menday <Roger.Menday@uk.fujitsu.com>
Date: Mon, 19 Nov 2012 22:50:54 +0000
CC: Linked Data Platform Working Group <public-ldp-wg@w3.org>
Message-ID: <D88B5AB8-6023-4037-8F9C-02DFB336A008@uk.fujitsu.com>
To: "Wilde, Erik" <Erik.Wilde@emc.com>

>>>> This specific issue wasn't about the 'storing' (the 'write') part.
>>>> I was specifically concerned with the reading part.
>>> given that LDP is a service and a service should only expose its service
>>> surface, you cannot make any assumptions that you reach deeply into some
>>> back-end storage. all you can interact with are LDP concepts, unless the
>>> service exposes additional affordances that give you more interaction
>>> capabilities.
>> Did I say something to suggest otherwise .. ?
>> I'm definitely *not* making assumptions about the back-end, only that it
>> can get exposed as a Graph. That's it.
> that already is an assumption, isn't it?

maybe, but, it's a quite reasonable one, don't you think ?  I'm making that assumption, since we're doing RESTful LinkedData, Linked data is already a graph (as is the web), so, I think it we are on solid ground with it!! :) 

> if you strictly talk
> service-level, maybe services just allow you to say "no-embed",
> "minimal-embed", and "full-embed", because that's all they allow you to
> ask for. you might remember the days when feeds sometimes would have those
> options, so that you could choose which one to subscribe to. it always
> meant a little different things with different providers, so in the end
> you needed to know the specific features of the feed provider you were
> interacting with.
>>> REST would require you to expose this in a way that clients can construct
>>> those URIs at runtime, just by interacting with the LDP server. since
>>> you
>>> cannot assume any specifics about the back-end, all you could do is
>>> have a
>>> framework for how servers can expose additional interaction affordances,
>>> in this case probably through a URI template. and then there would be a
>>> magical parameter that would be entirely opaque to LDP, that would be
>>> exposed by the LDP service. we are currently just in the process of
>>> designing such a "query template" media type
>> I would be interested in seeing that ... where is this design at the
>> moment ? 
> http://geofeeds.org/earthquakes/query_schema.xml is what is currently
> driving the forms for the feeds you can see aggregated on
> http://geofeeds.org/client/map_app .

I really like that. Can we re-use it in LDP (with a little bit of RDF'fication:) ) ? 

> this will change quite a bit, since
> this was our initial prototype we learned quite a bit from. the next
> version will be independent from feeds and contain a little bit more
> support for describing and documenting the variables of a URI template. i
> hope i'll finish some first draft next week or the week after that.

Just to state an option for issue.38 which should be considered. 
we could use SPARQL to do all the filtering/inlining that is needed. 

For reference, there is some related material about this issue.38 in section 4.1.6 of http://dmtf.org/sites/default/files/standards/documents/DSP0263_1.0.1.pdf


>> I think that something link driven must be possible. i.e. like on a
>> shopping site, where the facets change according to which other facets
>> are selected previously, etc etc ... I think that this kind of mechanism
>> can be copied, such that the query strings can be "built up".
> facets are yet another challenge (and interesting that you mention them,
> because we have a lot of faxing machinery to expose), so my current plan
> is to first get some proposals for queries done, and then look at how they
> hold up when you're building faceting interactions around them. faceting
> is hard, because it's so rich and always a sequence of steps instead of
> just one thing to expose.
> cheers,
> dret.

Received on Monday, 19 November 2012 22:51:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:17:33 UTC