Re: Editors draft now has inlining - issue-58

hello arnaud.

On 2013-07-10 16:12 , "Arnaud Le Hors" <lehors@us.ibm.com> wrote:
>When I recently looked at GSP again it occurred to me that beyond the
>difference on POST the one big difference I see between GSP and LDP is
>that GSP is much more precise on what triples one GETs when dereferencing
>a (graph)
> URI. The notion of resource boundary in LDP is basically implementation
>dependent and this inlining stuff makes it even more so.

that's definitely true, but i think it makes sense that it is that way. if
you have a query service, you want to have a well-defined query model
where it's predictable given a dataset and a query over it what to expect
as a result. that's pretty much the definition of a non-broken query
language.

however, LDP is not a query language, so it's acceptable (in my opinion)
if services have more freedom to decide how to implement certain things.
if we wanted LDP to be as strictly defined in terms of "dataset" and
"operations on it" as GSP, we again might end up recreating SPARQL,
instead of just creating a set of interactions that prescribe the
application flow with LDP resources, but do allow a certain degree of
freedom when it comes to nailing down every single detail in that flow.

fwiw, we use runtim-configurable inlining behavior in our services a lot,
and we do it because we believe that this allows a greater set of
applications to be built effectively. those which want to follow a
narrower path can disable inlining and get less overhead. those which want
to provide more options (for example for backing a rich UI with a lot of
options driven by the available resources) still don't have to "crawl" the
service and can request richer representations with more embedded
information. this certainly makes the service a bit more complex, but
hopefully makes a wider set of clients happy.

cheers,

dret.

Received on Thursday, 11 July 2013 08:13:11 UTC