Re: What does "being a member" mean?

* Henry Story <henry.story@bblfish.net> [2013-11-22 20:34+0100]
> 
> 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
> ...
> 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 .

If that's true (and I don't recall us having any RDFS or decisions
asserting that), the type args for any of the LDPC queries can be
omittied.


> ( 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. 
> }
> ]]
> )

I guess it seems likely that *if* an LDPC offered a query interface,
the base URI would be the LDPC. Of course, LDP makes no suggestion
about predictably instituting SPARQL interfaces on containers.


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

That query only works if you implement RDFS subPropertyOf semantics. I
don't expect LDP to require RDFS inference and without it you'd have
no clients which would see that <member{1,2,3}> were members of <>.


> 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

I think what you are challenging is the inital design choice to use
existing ontologies as membership triples. The complexity in the
current queries comes from this flexibility of expression. You would
prefer that we use a fixed predicate for either membership or
management (I thought the latter, but now I'm unsure) and that any
assertions in other ontologies are either generated by inference or,
if supplied as ground facts, either redundant or not authoritative
membership assertions.


> [[
> <> 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/
> 

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

Received on Saturday, 23 November 2013 17:17:23 UTC