Re: About the ldp:xyz relationship

On 5 Dec 2013, at 17:11, Arnaud Le Hors <lehors@us.ibm.com> wrote:

> Henry Story <henry.story@bblfish.net> wrote on 12/05/2013 03:02:30 AM:
> 
> > I did not understand the following statement:
> > 
> > [[
> > It is tempting to think that ldp:xyz should simply be ldp:member but
> > that would lead to a contradiction in the case of an 
> > IndirectContainer where this relationship links to an information 
> > resource which is not the member.
> > ]]
> > 
> > So in order to support that claim one needs to have definitions.   
> 
> Well, I'd argue that having formal definitions isn't strictly necessary, my wiki page gives you all the sparql queries you need to understand what these really are, but I agree formal definitions can help... if they are correct. :-) 

yes, the work we need to do is to get these definitions stable and precise.
We'll make huge strides as soon as we have done that.

> 
> > Below are the
> > ones I found, but I don't understand what the contradiction is meant
> > to be. Can 
> > you make that clearer?
> > 
> > ~~~~~~~~~~~~~~~~~~~8<~~~~~~~~~~~~~~~~~~8<~~~~~
> > ldp:member a rdf:Property;
> >   skos:editorialNote "this relation could also be called ldp:manages."
> >   rdfs:subPropertyOf rdfs:member;
> >   rdf:domain ldp:Container;
> >   rdf:range ldp:Resource; //<- this is intended to refer to the set of LDPRs and LDP Binaries. Find a name for it.
> >   w3c:voted <http://www.w3.org/2013/meeting/ldp/2013-11-25#ISSUE__2d_84>
> >   rdfs:comment """
> >     An ldp:member of a ldp:Container is a Resource which is created when a POST succeeds 
> >     on it (creating also the membership triples in the LDPC) or  which when DELETED 
> >    removes the membership triples as specified by the "Linked Data Platform 1.0" spec.""" . 
> 
> The above definition works for a SimpleContainer because in that case the resource that is created via POST is also the resource that gets added as a member. It doesn't work in the case of an IndirectContainer where the latter is not true. To work for IndirectContainer the range would need to be rdfs:Resource.

The point of ldp:member is to relate the resources created by the container and those that when
deleted or PATCHed change the container. The comment next to the rdfs:range line makes this clear: 
"this is intended to refer to the set  of LDPRs and LDP Binaries. Find a name for it."

rdfs:Resource will not do as a range of ldp:member. It covers much to large a field: it covers 
every possible object, where we only want ldp:Containers, ldp:Resources and ldp Binaries.

So a subpart of this problem is to name the resources that are LDPRs and binaries. 
Your wiki page has a section for it that would help:
  http://www.w3.org/2012/ldp/wiki/Membership#Binary.2Fnon-RDF_resources
If we can define the class of such Binary resources then we can union the LDPRs
and LDPBs and name the class of both.


> Look at the FOAF example: 
> 
> @base <http://example.org/arnaud>
> @prefix ldp: <http://www.w3.org/ns/ldp#>.
> @prefix foaf: <http://xmlns.com/foaf/0.1/> .
> 
> <> a ldp:IndirectContainer;
>  ldp:containerResource <#me>;
>  ldp:containsRelation foaf:knows;
>  ldp:insertedContentRelation foaf:primaryTopic ;
>  ldp:memberResource <http://example.org/steves> ;    # link to the information resource
>  ldp:memberResource <http://example.org/timbl> .    # link to the information resource
> 
> <#me> a foaf:Person;
>  foaf:knows <http://example.org/steves#me>;          # link to the member resource
>  foaf:knows <http://example.org/timbl#me>.          # link to the member resource 
> 
> <http://example.org/steves#me> is not an LDPR, right? <http://example.org/steves> is. 

Right. <http://example.org/steves#me> is a human being  I suppose.
So it is not something you can DELETE.  It is not something you can interact with using HTTP verbs. HTTP is a 
method of interacting with a web server on documents that describe things in the world.

So the point of ldp:member is clearly  much closer to what ldp:xyz is trying to get at,
since it is trying to tie Information resources together that the container is managing.
I'd like to think the server is not managing SteveS above.


> If we were to replace ldp:memberResource by ldp:member we would wrongly imply that <http://example.org/steves> is the member when it is not. <http://example.org/steves#me> is the member. 

I'd say you'd completely rightly infer that  <http://example.org/steves> is the ldp:member ,
and completely wrong to say that <http://example.org/steves#me> is the ldp:member .


> 
> Of course, you're might tell me that this is why calling <http://example.org/steves#me> the member is wrong but that's what adding insertedContentRelation, then called MembershipObject, was all about. Allowing one to have a container of real things (e.g., zaza the cat) rather than merely of documents/information resources that can be created via POST. 

The problem came way before that. Calling these relations "membership triples", then allowing the subject to point
to any object in the universe, then allowing any relations and allowing their inverses. That lead to the obvious 
question why the only object of these triples were information resources.

I don't have any trouble with ldp:insertedContentRelation .

But ldp:member is not a relation that relates ANY object to any OBJECT. It is exactly
to the contrary the relation that relates ldp:Container-s to ldp:Resource-s Union ldp:Binaries .

> 
> If anything this tells me that it's a bad idea to use ldp:member the way we do with SimpleContainer because it's going to be misleading people into believing that a member is necessarily an ldp:Resource when it's not. rdfs:member would be better suited. 

the problem is your use of "member" in "membership triples" in a completely unintuitive way, 
and has nothing to do with the english word member.  In english a member is always a member OF
something. In the membership triples one has no idea what is the member relation, what object
is the member of what. (unless one then consults the rules, which can tell one what the ldp:xyz
(a.k.a ldp:member ) is.

This is argued by ISSUE-85 "membership triples misnamed"
  https://www.w3.org/2012/ldp/track/issues/86


Anyway on the definition that was accepted of ldp:member,
the following is correct ( according to the going understanding of the spec )

PREFIX ldp: <http://www.w3.org/ns/ldp#>

CONSTRUCT { ?ldpc ldp:member ?resource }
WHERE {
  {
      ?ldpc ldp:member ?resource.                      # the information resource is the member
  } UNION {
      ?ldpc a ldp:DirectContainer;
        ldp:containerResource ?containerResource;
        ldp:containsRelation ?containsRelation.
      ?containerResource ?containsRelation ?resource.  # the information resource is the member
  } UNION {
      ?ldpc a ldp:DirectContainer;
        ldp:containerResource ?containerResource;
        ldp:containedByRelation ?containedByRelation.  # the information resource is the member
      ?resource ?containedByRelation ?containerResource.
  } UNION {
      ?ldpc a ldp:IndirectContainer;
        ldp:memberResource ?resource.                  # the information resource is linked via ldp:memberResource
  }
}





> 
> > 
> > 
> > ldp:memberResource owl:sameAs ldp:created;
> >    rdf:domain ldp:Container;
> >    rdf:range ldp:Resource //<- this is intended to refer to the set 
> > of LDPRs and LDP Binaries
> >    rdfs:comment """
> >      relates the resources created by a container
> >    """. 
> 
> We don't have ldp:memberResource and ldp:created. ldp:memberResource is ldp:created renamed. The rest is fine. 

Ok. But then see my reservations about ldp:memberResource not being the right relation for ldp:xyz . 

> 
> > 
> > ldp:xyz a rdf:Property;
> >   rdf:domain ldp:Container;
> >   rdf:range ldp:Resource; //<- this is intended to refer to the set 
> > of LDPRs and LDP Binaries. Find a name for it.  
> >   rdfs:comment """
> >     ldp:xyz relates an LDPC to the resources that it manages [link 
> > to the spec for Managed Resource] 
> >   """.
> > ~~~~~~~~~~~~~~~~~~~8<~~~~~~~~~~~~~~~~~~8<~~~~~
> 
> Yep. Which is why I said ldp:xyz matches ldp:membeResource. 

ldp:xyz goes beyond ldp:memberResource. 
As I understand ldp:memberResource replaces ldp:created. And ldp:created
was just linking an LDPC to an ldpr that was created via POST. 

ldp:xyz goes beyond that in that it also covers resources that may not
have been created by a POST. As long as the expectation of the client 
that interacting with them is the same as if they had, it is an ldp:xyz element
of the LDPC.

So I don't think that ldp:memberResource is the right relation.
But then of course if you redefine it, it could be. 

That is why having the definition up front and clear is really important.

> 
> > 
> > 
> > 
> > > --
> > > Arnaud  Le Hors - Software Standards Architect - IBM Software Group
> > 
> > Social Web Architect
> > http://bblfish.net/
> > 
> > 
> 
> --
> Arnaud  Le Hors - Software Standards Architect - IBM Software Group

Social Web Architect
http://bblfish.net/

Received on Thursday, 5 December 2013 17:14:28 UTC