Re: What does "being a member" mean?

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


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


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

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