Re: How to find the members of an LDPC?

On 11/08/2013 05:45 AM, Henry Story wrote:
>
> On 8 Nov 2013, at 05:52, Arnaud Le Hors <lehors@us.ibm.com> wrote:
>
>> Yes, I expected you to say that actually. :-)
>>
>> One possible solution would be to make ldp:created mandatory when ldp:insertContentRelation is anything other than ldp:MemberSubject.
>
> That's a good first solution and I'll +0.1, rather than +1 it, as it feels very much like a
> band aid, curing the symptom but not reaching the cause of the problem. Perhaps
> we can move quicker  to a solution that will make it to the final call.
>
> Consider:
>
> The above solution would work, but also requires the
> text to say something  along the lines that ldp:membershipXXX relations
> can NEVER CHANGE in an LDPC over time. Otherwise you have the same problem. Imagine
> that at one time the ldp:membershipObject ( now ldp:insertedContentRelation )
> is foaf:primaryTopic, at another time foaf:maker, ... or that at one time
> the ldp:merbershipProperty ( now ldp:containsRelation ) is foaf:knows,
> then family:father, and later family:boss. Any change at all like this would
> make it impossible to go from information about those relations back to the
> members of the names of the created resources.
>
> The above shows why the ldp:memberXXX relations should instead be considered
> as relating to the creation of a resource, as I argued in "volunteering for the
> army" http://lists.w3.org/Archives/Public/public-ldp-wg/2013Nov/0022.html
> They are consequences of creation, not inferential rules that allow one to
> go from relations to ldp:created (as I thought until recently)
>
> It seems to follow from the above that ldp:created should be listed for every resource
> of an ldpc.

General +1. ldp:containsRelation and ldp:created serve very different
purposes, it is very important not to make one depend on the other.

ldp:containsRelation together with ldp:containerResource and
ldp:insertedContentRelation are not essential to LDP. They are just a
set of instructions to configure an LDPC, which if it supports the
feature, would be able to interpret those instructions and manage some
application data while maintain the associated invariants from the
spec.

I would even argue that it should be defined outside of LDP core,
probably in a different spec that builds on top of LDP, as people
expect LDP to just define a simple protocol. That's basically the
approach taken by the people working on WebID and WebACL: there is no
circular dependency with LDP.

Alexandre.

>
> Henry
>
>
>> --
>> Arnaud  Le Hors - Software Standards Architect - IBM Software Group
>>
>>
>> Alexandre Bertails <bertails@w3.org> wrote on 11/07/2013 05:33:44 PM:
>>
>>> From: Alexandre Bertails <bertails@w3.org>
>>> To: Arnaud Le Hors/Cupertino/IBM@IBMUS,
>>> Cc: Linked Data Platform WG <public-ldp-wg@w3.org>
>>> Date: 11/07/2013 05:33 PM
>>> Subject: Re: How to find the members of an LDPC?
>>>
>>> On 11/07/2013 02:21 PM, Arnaud Le Hors wrote:
>>>> Hi Alexandre,
>>>>
>>>> As Henry pointed out we have ldp:created. See
>>>> http://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html#ldpc-5_4_14
>>>> Doesn't that address your problem?
>>>
>>> Yes it does, but the fact it is optional is an issue, especially when
>>> ldp:containsRelation is required. How does a client know that there is
>>> no member?
>>>
>>> Alexandre.
>>>
>>>>
>>>> In your example after the POST you would have:
>>>>
>>>> $ GET http://example.com/shopping/cart/
>>>> [[
>>>> </shopping/cart/> a ldp:Container;
>>>>      ldp:containerResource <#>;
>>>>      ldp:containsRelation order:contains;
>>>>      ldp:insertedContentRelation foaf:primaryTopic;
>>>>      ldp:created <the_url_of_the_resource_that_was_created>.
>>>>
>>>> <#> order:contains <urn:isbn:0470396792>.
>>>> ]]
>>>>
>>>> $ GET <the_url_of_the_resource_that_was_created>
>>>> [[
>>>> <> foaf:primaryTopic <urn:isbn:0470396792> .
>>>> ]]
>>>>
>>>> Best regards.
>>>> --
>>>> Arnaud  Le Hors - Software Standards Architect - IBM Software Group
>>>>
>>>>
>>>>
>>>>
>>>> From: Alexandre Bertails <bertails@w3.org>
>>>> To: Steve Speicher <sspeiche@gmail.com>,
>>>> Cc: Linked Data Platform WG <public-ldp-wg@w3.org>
>>>> Date: 11/07/2013 08:47 AM
>>>> Subject: Re: How to find the members of an LDPC?
>>>> ------------------------------------------------------------------------
>>>>
>>>>
>>>>
>>>> On 11/06/2013 09:01 AM, Steve Speicher wrote:
>>>>   > Hi,
>>>>   >
>>>>   >
>>>>   > On Tue, Nov 5, 2013 at 7:49 PM, Alexandre Bertails <bertails@w3.org
>>>>   > <mailto:bertails@w3.org>> wrote:
>>>>   >
>>>>   >     Hi guys,
>>>>   >
>>>>   >     I understand ldp:containerResource, ldp:containsRelation and
>>>>   >     ldp:insertedContentRelation as a _set of instructions_ for the
>>>> LDPC to
>>>>   >     manage some domain-based relations, but I don't see a way to find the
>>>>   >     LDPRs created by the LDPC.
>>>>   >
>>>>   >     Please consider the following example:
>>>>   >
>>>>   >     $ GET http://example.com/shopping/__cart/
>>>>   >     <http://example.com/shopping/cart/>
>>>>   >
>>>>   >     [[
>>>>   >     </shopping/cart/> a ldp:Container;
>>>>   >         ldp:containerResource <#>;
>>>>   >         ldp:containsRelation order:contains;
>>>>   >         ldp:insertedContentRelation foaf:primaryTopic.
>>>>   >     ]]
>>>>   >
>>>>   >     $ POST http://example.com/shopping/__cart/
>>>>   >     <http://example.com/shopping/cart/>
>>>>   >
>>>>   >     [[
>>>>   >     <> foaf:primaryTopic <urn:isbn:0470396792> .
>>>>   >     ]]
>>>>   >
>>>>   >     $ GET http://example.com/shopping/__cart/
>>>>   >     <http://example.com/shopping/cart/>
>>>>   >
>>>>   >     [[
>>>>   >     </shopping/cart/> a ldp:Container;
>>>>   >         ldp:containerResource <#>;
>>>>   >         ldp:containsRelation order:contains;
>>>>   >         ldp:insertedContentRelation foaf:primaryTopic.
>>>>   >
>>>>   >     <#> order:contains <urn:isbn:0470396792>
>>>>   >     ]]
>>>>   >
>>>>   >     Question: from the last GET, what is the LDPR for
>>>> <urn:isbn:0470396792>?
>>>>   >
>>>>   >
>>>>   >     If the ldp:member relation does not exist, how would a client deduce
>>>>   >     the members that were created
>>>>   >
>>>>   >     ?
>>>>   >
>>>>   >
>>>>   > One would assume that the POST would return a 201-Created status message
>>>>   > and Location header of the URL for the new resource created.  The server
>>>>   > may produce another triple to link the created resource (LDPR), not sure
>>>>   > what it might be:
>>>>   >      <> ex:describes <#>.
>>>>
>>>> For any Web API I have played with, listing (or querying) a
>>>> container/collection to retrieve the members it created was a basic
>>>> feature.
>>>>
>>>> Adding an ldp:member predicate which makes explicit the membership
>>>> relation between an LDPC and its LDPRs. But the ldp:containerResource
>>>> + ldp:containsRelation + ldp:insertedContentRelation thing (can we
>>>> have a name for _what_ this is?) is something different. I'm not
>>>> saying this is useless, but it addresses a different problem and it's
>>>> hard to justify why all application developers would have to deal with
>>>> that while simple interactions are not there.
>>>>
>>>>   >
>>>>   >     What really matters as client is to know what interactions are
>>>>   >     possible. If an interaction model were to be defined, I would expect
>>>>   >     to see something like that:
>>>>   >
>>>>   >     1. HTTP HEAD on </foo/> tells client "I am an LDPC" as it returns a
>>>>   >     header
>>>>   >         Link: <http://www.w3.org/ns/ldp#__Container
>>>>   >     <http://www.w3.org/ns/ldp#Container>>; rel="type"
>>>>   >
>>>>   >     2. from a GET on </foo/>, a client finds/deduces the LDPRs managed by
>>>>   >         </foo/> eg. with triples like { </foo/> ldp:member </foo/bar> }
>>>>   >
>>>>   >     3. HTTP HEAD on </foo/bar> tells client "I am an LDPR" as it returns
>>>>   >     a header
>>>>   >         Link: <http://www.w3.org/ns/ldp#__Resource
>>>>   >     <http://www.w3.org/ns/ldp#Resource>>; rel="type"
>>>>   >
>>>>   >     4. HTTP DELETE on </foo/bar> MUST remove the LDPR and remove
>>>>   >         { </foo/> ldp:member </foo/bar> } from the LDPC
>>>>   >
>>>>   > This is the interaction model defined by LDP ... with the exception of
>>>>   > ldp:member this isn't defined but think you are saying
>>>>   > ldp:containsRelation.  I can't tell if you are saying there is something
>>>>   > missing or you are just describing roughly how it works.
>>>>
>>>> We already know that the interaction is not hypermedia driven as we
>>>> agreed not to define a new media-type for LDP. Instead we have a Link
>>>> header for Resource. But I still need to look at the payload to know
>>>> about what interaction is possible with the resource. That means that
>>>> 1. and 3. don't really work like in my example.
>>>>
>>>> ldp:containsRelation is just an instruction targeting the LDPC to
>>>> manage some domain-related triples. So 2. just doesn't hold at all.
>>>>
>>>> Finally, 4. is really odd as I have no way (in the general case) to
>>>> know that an LDPC manages an LDPR or not.
>>>>
>>>> So yes, there are apparently several people believing that there are
>>>> basic missing things, and some incidental complexity which is hard to
>>>> justify.
>>>>
>>>> Alexandre.
>>>>
>>>>   >
>>>>   > - Steve
>>>>   >
>>>>   >     Alexandre.
>>>>   >
>>>>   >
>>>>
>>>>
>>>>
>>>
>
> Social Web Architect
> http://bblfish.net/
>
>

Received on Friday, 8 November 2013 15:53:25 UTC