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

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 ? 

I think we can use the same features we have been using until now ( ie: ldp:containedByRelation ). 
I tend to prefer the elegance of using owl:inverseOf :

<> ldp:containsRelation [ owl:inverseOf rel:father ] .

(this is assuming we go for solution 3.3
http://www.w3.org/2012/ldp/wiki/MembershipInferencing#Think_in_terms_of_causal_consequence_instead_of_logical_consequence )

Below for solution 3.4 the generalisation from that.

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

Not really. I just did not have then energy to write out the complete SPARQL rules. The wiki page is pretty long already.

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

You could do this 

<> ldp:creationConsequence [ ldp:subjectSelector  foaf:primaryTopic;
                               ldp:predicate [ owl:inverseOf order:belongsTo];
                               ldp:object <#> ]

or if we are worried about owl we go the current way 

<> ldp:creationConsequence [ ldp:subjectSelector  foaf:primaryTopic;
                               ldp:inversePredicate order:belongsTo;
                               ldp:object <#> ] .


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

I think it won't be more work than adding more and more patches that make the current rules more complex.
It may in fact be much easier because the spec will be much easier to understand, and so the spec writers will be much clearer
about what they have to write too.

It also means that vanilla servers won't have to implement ldp:creationConsequence at all, and this should mean we have a lot 
more implementations quickly.

So we get both default values, a meaningful feature which we can argue for clearly, and one that can be extensible in the future.

But the spec writers will be in the best position to tell us what this entails.

Henry


> 
> Best Regards,
> Nandana

Social Web Architect
http://bblfish.net/