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

hello roger.

On Nov 19, 2012, at 14:51, "Roger Menday" <Roger.Menday@uk.fujitsu.com> wrote:
>>> 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!! :) 

we're building a service and as such, we cannot expose implementation details. we want to allow and encourage LDP implementation on non-RDF back-ends. so what we can expose is the service surface including the interactions it affords, but assuming that service internals are RDF would go too far.

imagine Atom(Pub) would have specified XQuery for querying feeds assuming every implementation would run an XML DB and manage its data in XML. this would have made way too many assumptions about service internals and greatly dimished the service's value as an implementation-agnostic way for managing collections.

>> 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:) ) ? 

we might. the model will be represented as an XML-based media type, but if people think it must be RDF, deriving RDF from it is pretty much just a mapping exercise.

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

not really an option until we're effectively mandating RDF as the only possible implementation back-end. we must limit ourselves to just talk about LDP concepts.

cheers,

dret.

Received on Monday, 19 November 2012 23:49:31 UTC