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

Hi Roger,

On 05/30/2013 06:01 AM, Roger Menday wrote:
[snip]
>
> 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.

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

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

Received on Thursday, 30 May 2013 12:42:58 UTC