W3C home > Mailing lists > Public > public-ldp-wg@w3.org > November 2013

Re: Keeping the simple case simple (was Re: optimizing container pages serialization to enable streaming)

From: Henry Story <henry.story@bblfish.net>
Date: Fri, 15 Nov 2013 20:45:36 +0100
Cc: Linked Data Platform WG <public-ldp-wg@w3.org>
Message-Id: <BB3146F6-7796-4470-A211-FD02FD6D1611@bblfish.net>
To: Nandana Mihindukulasooriya <nmihindu@fi.upm.es>

On 15 Nov 2013, at 19:48, Nandana Mihindukulasooriya <nmihindu@fi.upm.es> wrote:

> Hi Henry,
> On Fri, Nov 15, 2013 at 7:07 PM, Henry Story <henry.story@bblfish.net> wrote:
> On 15 Nov 2013, at 15:53, John Arwe <johnarwe@us.ibm.com> wrote:
> > Being mindful of time zones ...
> >
> > Henry: from skimming the other two main branches, I see you're using the following wiki pages -- have any of them been eclipsed  by discussions already had, or should I still look at each in context later today?
> >
> > http://www.w3.org/2012/ldp/wiki/Member
> I just updated this.
> >
> > http://www.w3.org/2012/ldp/wiki/MembershipInferencing
> I like the idea of your proposal as it looks like a way to keep the simple things simple and make the complex things possible. One thing that I couldn't find was how one can put an inverse relationship (similar to membership inverse relationship that is currently there). Do you think it is necessary ? 
> So I guess according to your reasoning, it should be one of the consequences of POSTing (i.e. ldp:member will be always in forward direction). 
> Say if I want to insert a relation like 
> <urn:isbn:0470396792> order:belongsTo <#>;
> By using something like (for example),
> ldp:creationConsequence [ ldp:subjectSelector  foaf:primaryTopic;
>                                ldp:predicate order:belongsTo;
>                                ldp:objec <#> ]
> Also It would be also be helpful if you can try to tell a bit about the impact of the proposal on the current spec (i.e. which areas would need substantial changes) so that people can see how it will effect the timeline and other things. 

Note if ldp:member/manages is also accepted this 
makes it possible to show how SPARQL ties in with the protocol.

Once we have 

<> ldp:member <m1>, <m2>, <m3> .

We can think of <m1>, <m2> and <m3> as named graphs. The LDPC could then be
the default graph and so queried could be made to an LDPC as Alexandre Bertails
argued in Links and Graphs


To quote from that e-mail:

$ curl -X POST \
    --data-binary @query.sparql \
    -H "Content-Type: application/sparql-update; utf-8" \

where `query.sparql` is something like

.... WHERE {
  ?ldpcS ?ldpcP ?ldpcO .
  ?ldpcS ldp:created ?ldpr .
  GRAPH ?ldpr { ?ldprS ?ldprP ?ldprO } .
} ORDER BY ?ldprP

I am not saying this has to be specced here, but if we can point to that
to show that we are orthogonal with that work, then things are pretty neat.


> Best Regards,
> Nandana

Social Web Architect

Received on Friday, 15 November 2013 19:46:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:17:46 UTC