Member

From Linked Data Platform
Jump to: navigation, search

Following the question by Alexandre Bertails "What does "being a member" mean?", below is a proposal for the missing definition between an LDPC and the LDPR This following definition of ldp:member should allow us to speak of the relation between these three entities clearly:

  • LDPC
  • the membership triples
  • the LDPRs created when POSTing to an LDPC or that when DELETEd remove the membership triples 
@prefix ldp: <http://www.w3.org/ns/ldp#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org//2000/01/rdf-schema#> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .

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

Compare the above definition with that of ldp:created which ties the resource to the POST action on the ldpc. 

ldp:created a rdf:Property;
  rdf:domain ldp:Container;
  rdf:range ldp:Resource; 
  rdfs:comment """
     relates an ldp:Container to a LDPR which is created when a POST on the LDPC succeeds.
     (to decide: does DELETEing the LDPR makes the relation false? possible reason: because there would be no reference for the object of the relation. )
  """ .

1 Naming Issues

1.1 ldp:xyz / ldp:manages

As argued in ISSUE-89: Tie the interaction model with the LDP data model through the notion of Managed Resources the important part of what the above ldp:member relation attempts to defined above is not the name, but to express the relation that exists between an ldp:Container and a Resource, such that it is true when certain interactions defined by the spec are possible. Ie creation of a resource has consequences to what triples appear in an LDPC, or deletion/patching of a resource has consequences as to what relations appear in an LDPC, as show for example in the Membership page. 


@prefix ldp: <http://www.w3.org/ns/ldp#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org//2000/01/rdf-schema#> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .

The rdf for ldp:xyz could be the following:

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

So the question then is: should we call ldp:xyz

  • ldp:manages
  • ldp:member

1.2 Membership Triples

This is now tracked as Issue-86: "membership triples" misnamed.

It was argued that ldp:member could clash with the notion of "membership triples" as defined in the Linked Data Platform 1.0 spec:

Linked Data Platform Container (LDPC)
An LDPR representing a collection of membership triples which is uniquely identified by a URI that responds to client requests for creation, modification, and enumeration of its members.
Membership triples
A set of triples in an LDPC's state that lists its members. A container's membership triples all have one of the following patterns: 
membership-constant-URI	membership-predicate	member-URI
member-URI	membership-predicate	membership-constant-URI

The difference between the two is simply which position member-URI occupies, which is usually driven by the choice of membership-predicate. Most predicates have a natural forward direction inherent in their name, and existing vocabularies contain useful examples that read naturally in each direction. rdfs:member and dcterms:isPartOf are representative examples. Each container exposes properties that allow clients to determine which pattern it uses, what the actual membership-predicate and membership-constant-URI values are, and (for containers that allow the creation of new members) what value is used for the member-URI based on the client's input to the creation process.

There are two answers:

  • Use another term, perhaps ldp:manages
  • In fact ldp:member explains why "membership triples" are called that way. "membership triples" clearly have no relation to ldp:member other than their potentially being inferable from ldp:member via a Membership Inferencing rule such as either: 
    CONSTRUCT {
     ?subject ?relation ?object . 
    } WHERE { 
     ?ldpc ldp:membershipSubject ?subject;
              ldp:membershipPredicate ?relation;
              ldp:membershipObject ?memberRelation;
          ldp:member ?resource .
 
    GRAPH ?resource {
      ?resource ?memberRelation ?object . 
    }
  }

or inversely but with more issues ( such as the missing function from object to LDPR member ): 

   CONSTRUCT {
     ?ldpc ldp:member ?resource .
   } WHERE { 
      ?ldpc ldp:membershipSubject ?subject;
            ldp:membershipPredicate ?relation;
            ldp:membershipObject ?memberRelation .

     ?subject ?relation ?object .
 
     GRAPH ?resource {
         ?resource ?memberRelation ?object . 
     }
  }

or finally and most likely the membership predicates are consequences of LDPR creation as [argued in the Membership Inferencing Contractual/Causal Rule http://www.w3.org/2012/ldp/wiki/MembershipInferencing#Contract.2FCausal_rule]

Without one of these rules it would be difficult to explain how triples such as the following can have anything to do with "membership": 

  { <#> :doesNotHaveAsMember <#y> . }
  { <#x> a :Photon . }
  { <#z> loves <#y> . }

yet any of the triples in those three graphs could be created by a POST via the ldp:membershipXXX statements.

2 Advantages

Retrieved from "http://www.w3.org/2012/ldp/wiki/index.php?title=Member&oldid=3237"