- From: Andrei Sambra <andrei.sambra@gmail.com>
- Date: Sat, 9 Nov 2013 12:45:38 +0100
- 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>
- Message-ID: <CAFG79ejAoycr6K9a_ys1NswS2UPPAwOmpXpU=_AiZ5=M-ivA9A@mail.gmail.com>
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