ldp-ISSUE-86 (membershipTriples): "membership triples" misnamed [Linked Data Platform Spec]

ldp-ISSUE-86 (membershipTriples): "membership triples" misnamed [Linked Data Platform Spec]

http://www.w3.org/2012/ldp/track/issues/86

Raised by: Henry Story
On product: Linked Data Platform Spec

The spec has the definition for 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.
]]

Here are some examples of relations that could be termed "membership triples" according to the current spec:

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

How could any of these be considered to be "A set of triples in an LDPC's state that lists its members" ? The subject is not even an LDPC and the relation can be denying membership!

The word "member" here is very confusing. Better words of what these are may be "creation consequence" relations. Or "inferential consequences" or some such thing. But these are only indirectly related to membership of the two major constructs in LDP: the LDPC and the LDPR.

Received on Thursday, 14 November 2013 08:21:15 UTC