Re: What does "being a member" mean?

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/

Received on Friday, 22 November 2013 20:30:06 UTC