ldp-ISSUE-81 (onfusing predicate names): Confusing membership* predicate names and other possible improvements [Linked Data Platform Spec]

ldp-ISSUE-81 (onfusing predicate names): Confusing membership* predicate names and other possible improvements [Linked Data Platform Spec]

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

Raised by: Steve Speicher
On product: Linked Data Platform Spec

Reference: 30 July 2013 revision http://www.w3.org/TR/2013/WD-ldp-20130730/

The issue looks at a number of aspects of the membership behavior and predicates with respect to a LDP Container.  The motivation behind these items is to improve on the overall comprehension and usability of these concepts.  I am not raising issues with the model itself and other resolutions that led us to the model.  The goal is to have the same capability set as before.

================================================================
Item 1:  Confusion around the name of ldp:membershipObject, when comparing and contrasting with other ldp:membership* predicates

First, the object of a triple with predicate ldp:membershipObject is a predicate.

Secondly, ldp:membershipObject specifies the predicate that will be used to identify the triple from a “create new member resource” request used to determine the URI of the new member.

Proposal:
Rename ldp:membershipObject.  Suggestion ldp:indirectMemberPredicate (ldp:indirectMemberResourcePredicate, ldp:newMemberPredicate, ldp:newMemberTriplePredicate, ldp:???) as it more closely matches the definition.  This is the least bad we could come up with, perhaps someone has a better suggestion.

================================================================
Item 2: Confusion with ldp:membershipPredicate and ldp:membershipPredicateInverse

A triple containing one of these predicates identifies membership to a container and which position (subject or object) in the triple hold the member resource.  

Proposal: See next item

================================================================
Item 3: Confusion with ldp:membershipSubject when used with ldp:membershipPredicateInverse

In some applications the membership triples take the form:

   ( Member-resource, ?ldp:membershipPredicateInverse, ?ldp:membershipSubject ).

Which introduces the confusion as the ldp:membershipSubject is in the object position in the triple.

Proposal:
Keep ldp:membershipSubject, remove ldp:membershipPredicateInverse,repurpose ldp:membershipObject, and modify (slightly) the purpose of ldp:membershipPredicate.  
Remove from the definition of ldp:membershipPredicate the notion that the predicate defines that the subject of a triple containing the identified predicate holds the membership.
Define ldp:membershipObject to indicate that the object of the membership triples is actually holds the membership (same definition as ldp:membershipSubject but not in subject position, it is in object position).

================================================================
Item 4: Not making ldp:membershipObject required
(to be clear, the predicate formally known as ldp:membershipObject.  I will call it ldp:X and we will solve for X in item #1)

Proposal: See below

================================================================
Proposals: Pulling it all back together

It might be good to summarize all the proposals into some simple examples and definitions.

For the simple case where the membership triples take the form where the members are identified by the objects of those triples we have:

<> : rdf:type ldp:Container;
 ldp:membershipSubject <>;
 ldp:membershipPredicate rdfs:member.

Or in the case where the subject holds the member resources:

<> : rdf:type ldp:Container;
 ldp:membershipObject <>;
 ldp:membershipPredicate skos:inScheme.

Only change is ldp:membershipSubject has been replaced by ldp:membershipObject, and the membership predicate is now skos:inScheme.  Very consistent between the ways membership can be expressed.  In each case, the portion of the membership triple pattern that is omitted is “the variable”.

Then we can add vocabulary for alternative creation behavior such as:

<> : rdf:type ldp:Container;
 ldp:membershipSubject <>;
 ldp:membershipPredicate rdfs:member;
 ldp:indirectMemberPredicate foaf:primaryTopic.

Note: this may have a monotonicity problem, perhaps we can redirect that by introducing a new predicate (replacing the ldp:indirectMemberPredicate shown above) that indicates behavior, such as:
 
<> : rdf:type ldp:Container;
 ldp:membershipSubject <>;
 ldp:membershipPredicate rdfs:member;
ldp:containerCreationBehaviorOnPOST ldp:insertNewInformationResource.

The result above is not too satisfactory in that we need to insert the ldp:containerCreationBehaviorOnPOST triple to solve avoid a monotonicity problem.  Decoupling insertion behavior from the choice of member URI would also mean when we want to change the behavior and use indirect membership our container looks like the following.  We gain yet another triple (ldp:indirectMemberPredicate) when indirect membership is used, to communicate the remainder of what ldp:membershipObject communicates in the Last Call draft:

<> : rdf:type ldp:Container;
 ldp:membershipSubject <>;
 ldp:membershipPredicate rdfs:member;
ldp:containerCreationBehaviorOnPOST ldp:insertObjectfromRepresentationTriple;
 ldp:indirectMemberPredicate foaf:primaryTopic.

Potentially worth noting: 
 - ldp:containerCreationBehaviorOnPOST is NOT required.  If it is absent, then a client simply has no ldp-defined information on the matter it covers.  Read-only containers might not provide any value.  On the other hand having a value does give a client evidence that “inserts” should work, even if it does not provide the specificity of which HTTP method(s) support create/insertion.
 - ldp:indirectMemberPredicate is NOT required.  If it is absent, then a client simply has no ldp-defined information on the matter it covers.  Read-only containers might not provide any value; ditto read-write containers with other behaviors.
 - Thus, it does succeed in keeping the simple case simple.

Received on Friday, 6 September 2013 19:49:05 UTC