Re: Missing use case for supporting ldp:membershipPredicate/Subject

hi Alexandre, 

>> If you have a generic LD client, which is following links and
>> dereferencing URLs, I really don't see why you need to worry about
>> GETing an LDPC. I think that a generic LD client (which is conversant
>> with LDP), navigates LDPRs, and uses LDPC's support the non-read
>> interaction.  I'm just re-iterating what I said yesterday here on that,
>> really, but, I recognise that there are differing opinions on that :) !!
> 
> It's actually as important for the client to explore LDPC-s than
> LDPR-s.

The LDPC is a list of same-subject, same-predicate triples. So, according to me, when navigating LDPRs, I am already getting the information also inside the LDPCs. 

That same principle can be used to design for the specific case of raw graph management. This is why I don't agree with the argument about extensibility which you put forward below. Actually, on the contrary it seems to me that if the only predicate which can be managed by LDP is rdfs:member then this is placing a restriction. 

> 
>> Regarding your comment about  SPARQL. I agree that a SPARQL endpoint is
>> really useful (but optional). In my opinion (or for my usecases at
>> least), I would expect that the default graph behind a SPARQL endpoint
>> would cover a *group* of related LDPR resources (it might be useful to
>> have a link from each LDPR to that useful SPARQL endpoint).
> 
> I of course completely agree with SPARQL being "optional" in the
> context of this WG. I just want to make sure this is still feasible,
> just like WebACL, WebID, etc.
> 
> We should consider that there is one meta item in UC&R: don't
> overconstrain the API and develop with extensibility in mind.
> 
>> What I am really taking from your comment here is how it exposes the
>> differences in how people are viewing LDP. It seems clear to me that you
>> want to use LDP to do "Documents about Things into Boxes". Would you
>> agree ?
> 
> I thought that LDP was just about bridging the gap between RDF and the
> Web through a restful API, mostly for the concept of collections.

> I wouldn't try to rephrase that :-)

I'm not really trying to re-phrase - just trying to clarify why people think about LDP in different ways. According to our charter it says "HTTP-based (RESTful) application integration patterns using read/write Linked Data." ... 

thanks, 
Roger


> 
>> You might argue next that that the only thing that we should be
>> doing with LDP :) !!
> 
> Certainly not :-) LDP is just the beginning for building more complex
> things on top of it, SPARQL endpoint being one of them.
> 
>> Actually, I think that is the fundamental reason
>> why we are having this blast of intensity in the discussions right now.
> 
> Here is why I'm still discussing these issues: some people here
> believe that removing the support for overriding the LDP ontology
> would be limiting the flexibility of the technology. I'm actually
> fighting against keeping it for the exact same argument of flexibility
> and extensibility.
> 
> I believe that we have enough evidence now that asking for people to
> support the features related to this approach will further limit
> extensibility of the technology. And different people have pointed at
> some other problems.
> 
> In the world of software development, we achieve flexibility by
> limiting the scope of the interfaces being defined, and thinking twice
> about their semantics and how they relate to each other.
> 
> Alexandre.
> 
>> 
>> regards,
>> Roger
>> 
>> 
>>> 
>>> Also, what happens if there is both rdfs:member and
>>> ldp:membershipPredicate? The problem is that we cannot make a choice
>>> easily. We have to be ready to change the state of the client
>>> depending on some property, which may happens at any moment (the
>>> content could be streamed). This is an extra constraint on the client
>>> that seems not necessary.
>>> 
>>> Here is another argument. Let's say you want to extend an LDPC with
>>> some SPARQL capabilities (that's very natural), where the LDPC is the
>>> default graph and its members are named graphs. Now try to think about
>>> the query that would give you these members and you'll see that there
>>> is something wrong, as you need to handle two cases: with and without
>>> ldp:membershipPredicate. For me this is really fishy.
>> 
>>> I hope this is enough for discouraging people from making this a new
>>> entry in UC&R.
>>> 
>>> Alexandre.
>>> 
>> 
>