Re: What does "being a member" mean?

On 22 Nov 2013, at 23:27, Ashok Malhotra <ashok.malhotra@oracle.com> wrote:

> Henry:
> A couple of points:
> 1.  There is a view that collections are merely views over the triples hosted by the server.
> That is, a selection of triples by subject and predicate.  Your proposal links the collection
> and its members directly which is contrary to this view.

The concept of membership in the current spec is quite complicated as shown
in the wiki page under discussion:

  http://www.w3.org/2012/ldp/wiki/Membership

I believe that these are misnamed, since one can have membership triples that
have nothing to do with membership at all. See issue-86 
https://www.w3.org/2012/ldp/track/issues/86

But I don't think that they don't make sense. In fact I think that there is an 
important reason why they are so attractive to a business community that is 
clearly very present on this mailing list. What is trying to be expressed
by what used to conventiently be referred to as the ldp:membershipXXX triples
is what the consequences of POSTing are - which in philosophy of logic is known
as a  speech act, of which one of the most famous American Philosophers still living
in Berkley recently wrote up in a book: "Making the Social World: The structure of Human
civilisation"
http://www.amazon.com/Making-Social-World-Structure-Civilization-ebook/dp/B0031OQ0OW/ref=sr_1_1?ie=UTF8&qid=1385215242&sr=8-1&keywords=John+Searle

You will find more details here:
  http://www.w3.org/2012/ldp/wiki/MembershipInferencing#Think_in_terms_of_causal_consequence_instead_of_logical_consequence


> 2.  ldp:created would only apply to members created by doing a POST to a collection.
> What about members created by other means?  What about non-RDF members?
> All the best, Ashok

yes, that is why I propose to use ldp:member, ldp:xyz, _OR_ ldp:manages instead of
ldp:created. 

Those are defined here:
  http://www.w3.org/2012/ldp/wiki/Member
( which I have just updated to point to the latest issues )

If your second question is one about binaries, then I think that that
is another issue. I would have ldp:member ( aka ldp:xyz or ldp:manages )
related LDPCs to Information Resources that are both binaries or RDF members.

Then one solution is to have something like the following

<> a ldp:Container;
   ldp:xyz <member1>, <member2> .

<member1> a ldp:Graph .
<member2> a ldp:Binary;
          xxx:type "image/*" .

There are a number of other ways of solving this problem.

> 
> On 11/22/2013 2:34 PM, Henry Story wrote:
>> On 22 Nov 2013, at 16:40, Eric Prud'hommeaux <eric@w3.org> wrote:
>> 
>>> * Arnaud Le Hors <lehors@us.ibm.com> [2013-11-21 11:21-0800]
>>>> Hi all,
>>>> In an effort to clarify what we currently have in the spec I put a page
>>>> together on our wiki that I invite you all to read:
>>>> 
>>>> http://www.w3.org/2012/ldp/wiki/Membership
>> Impact of making ldp:created mandatory in all cases
>> ===================================================
>> 
>> http://www.w3.org/2012/ldp/wiki/Membership#Impact_of_making_ldp:created_mandatory_in_all_cases
>> 
>> 1. Query Simplicity
>> -------------------
>> 
>> It says that the query becomes:
>> 
>> [[
>> PREFIX ldp: <http://www.w3.org/ns/ldp#>
>> 
>> SELECT ?ldpc ?resource
>> WHERE {
>>       ?ldpc a ldp:Container;
>>         ldp:created ?resource.
>> }
>> ]]
>> 
>> In fact the query can be simplified to
>> 
>> [[
>> PREFIX ldp: <http://www.w3.org/ns/ldp#>
>> 
>> SELECT ?ldpc ?resource
>> WHERE {
>>       ?ldpc ldp:created ?resource.
>> }
>> ]]
>> 
>> since the domain of ldp:Created is an ldp:Container .
>> 
>> ( When querying an LDPC the query can be made even more specific by asking
>> 
>> [[
>> PREFIX ldp: <http://www.w3.org/ns/ldp#>
>> 
>> SELECT ?resource
>> WHERE {
>>       <> ldp:created ?resource.
>> }
>> ]]
>> )
>> 
>> 2. duplication
>> --------------
>> 
>> The text says "This simplifies queries at the cost of extra membership arcs. "
>> I disagree. If anything ldp:created should be a sub relation of rdfs:member.
>> ie:
>> 
>>   ldp:created rdfs:subPropertyOf rdfs:member .
>> 
>> Therefore all the duplicates can be ignored. Ie one only needs the container
>> to be:
>> 
>> [[
>> @base <http://example.org/container1/>
>> @prefix dcterms: <http://purl.org/dc/terms/>.
>> @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
>> @prefix ldp: <http://www.w3.org/ns/ldp#>.
>> 
>> <>
>>    a ldp:Container;
>>    ldp:containerResource <> ;
>>    ldp:containsRelation rdfs:member;
>>    ldp:insertedContentRelation ldp:MemberSubject;
>>    dcterms:title "A very simple container";
>>    ldp:created <member1>, <member2>, <member3>.
>> ]]
>> 
>> 3. in perspective of ldp-ISSUE-85 (causation) & ISSUE-89 (ldp:xyz)
>> ------------------------------------------------------------------
>> 
>> To go one step further, I would argue that if one thinks of
>> ldp:containerResource, ldp:containsRelation and ldp:insertedContentRelation
>> as forming a rule on what should happen when one POSTs, and not a way to infer
>> from membership triples to ldp:created resources ( or more generally to ldp:xyz
>> resources as defined by ISSUE-89 ) then one can simplify the above to the
>> following
>> 
>>  [[
>> <> a ldp:Container;
>>     ldp:created <member1>, <member2>, <member3>.
>> ]]
>> 
>> or considering ISSUE-89
>> 
>> [[
>> <> a ldp:Container;
>>     ldp:xyz <member1>, <member2>, <member3>.
>> ]]
>> 
>> which of course would be easier to read as
>> 
>> [[
>> [[
>> <> a ldp:Container;
>>     ldp:manages <member1>, <member2>, <member3>.
>> ]]
>> 
>> That is the point of ISSUE-85
>> 
>> 
>> 
>>> Executive summary:
>>>  example data for all patterns of membership triples.
>>>  SPARQL queries which reach all members regardless of pattern.
>>>  comparison with ldp:manages proposal.
>>> 
>>> 
>>>> I'm hoping this will help the discussion moving forward as it is relevant
>>>> to all the issues that we have on our agenda for Monday:
>>>> 
>>>>    ISSUE-84 ldp:member
>>>>    ISSUE-85 membershipXXX rules
>>>>    ISSUE-86 "membership triples" misnamed
>>>>    ISSUE-89 Managed resources
>>>> 
>>>> Regards.
>>>> --
>>>> Arnaud  Le Hors - Software Standards Architect - IBM Software Group
>>> -- 
>>> -ericP
>>> 
>>> office: +1.617.599.3509
>>> mobile: +33.6.80.80.35.59
>>> 
>>> (eric@w3.org)
>>> Feel free to forward this message to any list for any purpose other than
>>> email address distribution.
>>> 
>>> There are subtle nuances encoded in font variation and clever layout
>>> which can only be seen by printing this message on high-clay paper.
>> Social Web Architect
>> http://bblfish.net/
>> 
>> 
> 
> 

Social Web Architect
http://bblfish.net/

Received on Saturday, 23 November 2013 14:11:50 UTC