Difference between revisions of "Member"

From Linked Data Platform
Jump to: navigation, search
(Naming: minor fix)
Line 98: Line 98:
  
 
yet any of the triples in those three graphs could be created by a POST via the ldp:membershipXXX statements.
 
yet any of the triples in those three graphs could be created by a POST via the ldp:membershipXXX statements.
 +
 +
== Advantages ==
 +
 +
* it become easy [http://www.w3.org/2012/ldp/wiki/MembershipInferencing to specify the relation between "membership triples" and created resources]
 +
* it becomes easy to explain how an  [http://lists.w3.org/Archives/Public/public-ldp/2013Nov/0009.html LDPC could be used as a SPARQL endpoint]
 +
* Vanilla servers may just want to publish the ldp:member information
 +
* Vanilla clients that want to find the LDPRs of a Container can find them with no complex inferencing ( avoiding issues [http://www.w3.org/2012/ldp/wiki/MembershipInferencing#Problems such as those described in MembershipInferencing] )

Revision as of 09:44, 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. )
  """ . 

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

2 Advantages