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

Re: How to find the members of an LDPC?

From: Andrei Sambra <andrei.sambra@gmail.com>
Date: Sat, 9 Nov 2013 12:45:38 +0100
Message-ID: <CAFG79ejAoycr6K9a_ys1NswS2UPPAwOmpXpU=_AiZ5=M-ivA9A@mail.gmail.com>
To: Alexandre Bertails <bertails@w3.org>
Cc: Henry Story <henry.story@bblfish.net>, Arnaud LeHors <lehors@us.ibm.com>, Linked Data Platform WG <public-ldp-wg@w3.org>
On Fri, Nov 8, 2013 at 4:53 PM, Alexandre Bertails <bertails@w3.org> wrote:

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


+1

A rule vocabulary would greatly complement LDP, though it makes sense to
keep the interaction model apart from the data model (maybe in a
complementary spec).

Andrei


>  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 Saturday, 9 November 2013 11:46:25 UTC

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