Re: What does "being a member" mean?

On 23 Nov 2013, at 22:48, Eric Prud'hommeaux <eric@w3.org> wrote:

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

I am not sure how much you can deduce from the inferencing capacities
of Sesame, which might have been tuned for specific use cases.

But one can put the case the other way. Why would anyone want to 
have ldp:containsRelation be rdfs:member when ldp:created implies it
anyway. You might as well just have ldp:containsRelation be ldp:created .

No need for inferencing here at all.

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

From the point of view of "Membership Inferencing" the answer is 2.
--------------------------------------------------------------------

http://www.w3.org/2012/ldp/wiki/MembershipInferencing#Think_in_terms_of_causal_consequence_instead_of_logical_consequence

But 2 does not have redundant triples. Because you cannot infer from 

   <> ldp:created </entry2> . 

that
   
  </entry2> skos:inScheme <>.
   
because the ldp:membershipXXX relation may have changed since the
the time the </entry2> was created. 

That is the same as with legislation. It only applies from the point
in time onwards at which the legislation is passed. People who did
not wear seatbelts before seatbelt laws were required did not do anything
illegal. A person who signs a contract at one time, is not signing the same
contract if he signs it a year later. etc....

So the only requirement in my view on a client that sees those triples is
that he understand that by POSTing at that time he will be creating those
"membership triples" and so will be responsible for their creation.

If the ldp:membershipXXX rules change later then the client can no longer
be responsible for those changes (unless those are just logical consequences
of what was there before )

What your answer presupposes 
----------------------------

Is 1. because you presuppose that one can deduce 

 <> ldp:created </entry2> .

from the ldp:membershipXXX statements.

But if one can do that then one could reverse the rules, and be
just as well off. In which case one might as well just have the
simpler

   <> ldp:created </entry2> . 

And more advanced clients could deduce the "membership triples".

Henry


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

Social Web Architect
http://bblfish.net/

Received on Saturday, 23 November 2013 22:49:21 UTC