Re: What does "being a member" mean?

* Henry Story <henry.story@bblfish.net> [2013-11-23 18:34+0100]
> 
> On 23 Nov 2013, at 18:16, Eric Prud'hommeaux <eric@w3.org> wrote:
> 
> > * 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.
> 
> yes, though it seems pretty obvious that it should be the case.
> I'll create an issue once we have discussed ldp:xyz, ldp:member,
> ldp:manages to make sure this is in whatever is selected.
> 
> It looks like ldp:created is not in the ontology yet.
> 
> > 
> > 
> >> ( 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.
> 
> yes, that was just a parenthesis looking at what would be the case if
> as an interesting option left open by 
> ISSUE-90: An LDPC/LDPR is a Named Graph 
> https://www.w3.org/2012/ldp/track/issues/90
> 
> > 
> > 
> >> 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 <>.
> 
> IT seems odd that you are worried about a tiny rdfs inferencing such
> as this but seem to have been willing to accept clients to require
> some incredibly complex inferencing as described in 
> 
>    http://www.w3.org/2012/ldp/wiki/Membership

Those queries are trivial compared to one which includes general RDFS
reasoning. (Iirc, Sesame had a SPARQL compiler which included a fair
amount of RDFS, but it never caught stuff like :Fido a :Mammal in
  :p s:subPropertyOf s:subClassOf. :Fido a :Dog. :Dog :p :Mammal.
or :Fido a :Dog in
  :p2 s:domain :Dog. :p1 s:subPropertyOf :p2. :Fido :p1 :foo.

Even reducing RDFS to just subPropertyOf leaves you with quite complex
queries involving property paths on every predicate.


> >> 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.
> 
> Not at all. I am trying to make sense of the flexibility required
> by the membership triples framework. This flexibility makes sense
> in my view if you don't think it terms of inferencing, but in terms
> of triggers related to creation. It makes perfect sense that a spec
> such as LDP that is concerned about the action of creation using HTTP
> verbs, should specify consequences of creation which could be any type
> of statement whatsoever. It's just that I would not call them "membership
> triples" but "creation consequences" or some such. Wikipedia has an
> interesting article on Speech Acts that may help us find the right
> word
>   http://en.wikipedia.org/wiki/Speech_acts
> 
> Anyway, whatever the other consequences of POSTing to an LDPC,
> the one consequence of a successful post is that a fact of the 
> form
> 
>  ldpc ldp:created newResource .
> 
> becomes true.

Taking <http://www.w3.org/2012/ldp/wiki/Membership#exSKOS>, which
triples get added to the container on a POST?

  1. </entry2> skos:inScheme <>.
  2. </entry2> skos:inScheme <>. <> ldp:created </entry2> .
  3. <> ldp:created </entry2> .

1 is the current scheme.
2 has redundant triples.
3 eliminates the reuse of existing predicates.


> >> [[
> >> <> 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.
> 
> 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 21:48:48 UTC