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

hello roger.

On 2012-11-19 13:49 , "Roger Menday" <Roger.Menday@uk.fujitsu.com> wrote:
>>On 2012-11-19 09:19 , "Roger Menday" <roger.menday@uk.fujitsu.com> wrote:
>>> 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? 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 . 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.

>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:14:57 UTC