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

hello 

>>>> 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

regards,
Roger

>> 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.
>