Difference between revisions of "Member"

From Linked Data Platform
Jump to: navigation, search
(minor edit, and addition of pointer)
Line 86: Line 86:
 
   }
 
   }
 
   </pre>
 
   </pre>
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]
+
 
 +
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
 
Without one of these rules it would be difficult to explain how triples such as the following can have anything to do

Revision as of 09:29, 16 November 2013

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 that allows interaction with the 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.

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

Naming

It was argued that ldp:member could clash with the notion of "membership triples". 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 as argued the Membership Inferencing page in the section on causal consequence