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

On 20 Nov 2012, at 00:48, "Wilde, Erik" <> wrote:

> hello roger.
> On Nov 19, 2012, at 14:51, "Roger Menday" <> 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.

You can map anything to RDF, so there being an RDF interface makes absolutely no requirement on the backend storage. It's all about the API, and at that level we are doing things semantically, i.e.: with RDF here.

If you have sql backend you can use rdb2rdf backend.  You could use a file system backend if you wish - that's what we dead with read-write-web prototype a year ago.

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

That is Atom(Pub) this is LDP. For those who want Atom(Pub) atom(Pub) already exists. We are hering mapping this to RDF, which essentially will make it possible to work with any syntax.

>>> is what is currently
>>> driving the forms for the feeds you can see aggregated on
>>> .
>> 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.

Social Web Architect

Received on Tuesday, 20 November 2012 00:28:23 UTC