Re: membershipSubject clarification

hi Henry, 

As POSTed content creates a document, I can see your point that you *don't* want the address of the document in the object position of the triple. In [1] I suggested using the foaf:primaryTopic (or similar), that the server may use to find the address of the necessary 'thing' (not doc). Work for you ? 

As for your second point, I can see why people would find it useful, and I don't think it is necessarily contradictory and probably these things co-exist. I think it all depends on your LDP perspective. Either (1) manipulating Linked Data using containers, or (2) manipulating containers using Linked Data. I am type.1, and I am guessing you are type.2 (?)

regards, 
Roger

[1] http://lists.w3.org/Archives/Public/public-ldp-wg/2013Apr/0120.html


> 
> On 30 Apr 2013, at 18:11, Arnaud Le Hors <lehors@us.ibm.com> wrote:
> 
>> Hi all, 
>> On Monday we agreed to close Issue-61 which suggested to drop membershipSubject and focus on clarifying the spec instead. 
>> To get us started I'd like to highlight that the editor's draft has an expanded example 3 which may clarify things a bit: 
>> 
>> # The following is an elaborated representation of
>> #   http://example.org/netWorth/nw1
>> @prefix ldp: <http://www.w3.org/ns/ldp#>.
>> @prefix o: <http://example.org/ontology/>.
>> <>
>>  a o:NetWorth;
>>  o:netWorthOf <http://example.org/users/JohnZSmith>;
>>  o:asset 
>>     <assetContainer/a1>,
>>     <assetContainer/a2>;
>>  o:liability 
>>     <liabilityContainer/l1>,
>>     <liabilityContainer/l2>,
>>     <liabilityContainer/l3>.
>> 
>> <assetContainer/>
>>  a ldp:Container;
>>  dcterms:title "The assets of JohnZSmith";
>>  ldp:membershipSubject <.>;
>>  ldp:membershipPredicate o:asset.
>> 
>> <liabilityContainer/>
>>  a ldp:Container;
>>  dcterms:title "The liabilities of JohnZSmith";
>>  ldp:membershipSubject <.>;
>>  ldp:membershipPredicate o:liability. 
>> 
>> This defines two containers (assetContainer and libabilityContainer) corresponding two different membership predicates (respectively o:asset and o:liability) around the same subject resource (netWorth/nw1). 
> 
> 1. does the ldp:membershipSubject have to be a document such as <> ? ( which in the example above is a o:NetWorth )
>    a. if yes: how would one add a relation to a thing such as a person <#me> a foaf:Person ?
>    b. if no: why is the relation called membership subject? Does this imply that the o:asset relation is an rdf:subProperty of rdf:member.
>      I don't think that if I want to create a document I want to necessarily think of the document I created in say <assetContainer> as being a ldp:member of me.
> 
>  Consider the following example
> 
>   {
>      <#me> a foaf:Person;
>      foaf:depicts <portrait/img1> ;
>      cal:attending <meetings/meet1> .
> 
>       <portrait/> a ldp:Container;
>         dcterms:title "The assets of JohnZSmith";
>         ldp:membershipSubject <#me>;
>         ldp:membershipPredicate foaf:depicts.
> 
>       <meetings/>
>         a ldp:Container;
>         dcterms:title "The liabilities of JohnZSmith";
>         ldp:membershipSubject <.>;
>         ldp:membershipPredicate cal:attending. 
>    } 
> 
>    Is this ok?
> 
> 2. Would it not be a good thing if a GET on <portrait/> returned the following
> 
>    <> a ldp:Container;
>         dcterms:title "The assets of JohnZSmith";
>         ldp:membershipSubject <#me>;
>         ldp:membershipPredicate foaf:depicts;
>         rdfs:member <img1>, <img2> .
> 
>    and of course if <meetings> mentioned its rds:member ?
> 
> 3. What if I want the object of the relation from the ldp:membershipSubject to the the object to be something described by the created  
> resource? Say I want to create a resource that contains a <#me> and the ldp:membershipPredicate should be a foaf:knows relation to the object
> ( perhaps a <#him> in the created document? )
> 
> 4. Can I have a number of different membershipSubjects?
> 
> Guess
> -----
> 
>  My feeling is that what is wanted is some way to describe how contents of the POSTed
> graph get tied to other resources managed by the server. My feeling is that this is
> a good idea, but orthogonal to the rdf:member of an LDPC. 
> 
> Henry
> 
>> 
>> I would appreciate if Henry and others could ask specific questions about this design so we can try to answer them and see how the spec needs to be clarified. 
>> 
>> Thanks.
>> --
>> Arnaud  Le Hors - Software Standards Architect - IBM Software Group
> 
> Social Web Architect
> http://bblfish.net/
>