ISSUE-81: Confusing membership* predicate names and other possible improvements

confusing predicate names

Confusing membership* predicate names and other possible improvements

State:
CLOSED
Product:
Linked Data Platform Spec
Raised by:
Steve Speicher
Opened on:
2013-09-06
Description:
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.
Related Actions Items:
No related actions
Related emails:
  1. LDP Rec (from eric@w3.org on 2015-02-20)
  2. Re: LDP agenda for 11 November (from henry.story@bblfish.net on 2013-11-10)
  3. volunteering for the army (from henry.story@bblfish.net on 2013-11-06)
  4. Re: ISSUE-81: Confusing membership* predicate names and other possible improvements (from henry.story@bblfish.net on 2013-10-15)
  5. Re: ISSUE-81: Confusing membership* predicate names and other possible improvements (from pierre-antoine.champin@liris.cnrs.fr on 2013-10-15)
  6. Re: ISSUE-81: Confusing membership* predicate names and other possible improvements (from henry.story@bblfish.net on 2013-10-15)
  7. Re: ISSUE-81: Confusing membership* predicate names and other possible improvements (from pierre-antoine.champin@liris.cnrs.fr on 2013-10-15)
  8. Re: ISSUE-81: Confusing membership* predicate names and other possible improvements (from henry.story@bblfish.net on 2013-10-15)
  9. Re: ISSUE-81: Confusing membership* predicate names and other possible improvements (from lehors@us.ibm.com on 2013-10-14)
  10. ISSUE-81: Confusing membership* predicate names and other possible improvements (from henry.story@bblfish.net on 2013-10-14)
  11. Re: ISSUE-81 Suggested Name Changes (from lehors@us.ibm.com on 2013-10-10)
  12. Re: ISSUE-81 Suggested Name Changes (from sspeiche@gmail.com on 2013-10-01)
  13. Re: ISSUE-81 Suggested Name Changes (from johnarwe@us.ibm.com on 2013-10-01)
  14. Re: ISSUE-81 Suggested Name Changes (from lehors@us.ibm.com on 2013-09-30)
  15. Re: ISSUE-81 Suggested Name Changes (from sspeiche@gmail.com on 2013-09-30)
  16. Re: ISSUE-81 Suggested Name Changes (from johnarwe@us.ibm.com on 2013-09-30)
  17. Re: ISSUE-81 Suggested Name Changes (from sspeiche@gmail.com on 2013-09-30)
  18. Re: ISSUE-81 Suggested Name Changes (from johnarwe@us.ibm.com on 2013-09-17)
  19. Re: ISSUE-81 Suggested Name Changes (from tthibodeau@openlinksw.com on 2013-09-16)
  20. Re: ISSUE-81 Suggested Name Changes (from sspeiche@gmail.com on 2013-09-16)
  21. ISSUE-81 Suggested Name Changes (from david@3roundstones.com on 2013-09-14)
  22. Re: ldp-ISSUE-81 (Confusing predicate names): [Linked Data Platform Spec] (from tthibodeau@openlinksw.com on 2013-09-13)
  23. Re: ldp-ISSUE-81 (Confusing predicate names): [Linked Data Platform Spec] (from tthibodeau@openlinksw.com on 2013-09-13)
  24. ldp-ISSUE-81 (onfusing predicate names): Confusing membership* predicate names and other possible improvements [Linked Data Platform Spec] (from sysbot+tracker@w3.org on 2013-09-06)

Related notes:

Resolution:

Regarding Part I: Confusing predicate names, accept John's renaming proposal as the basis moving forward
See http://www.w3.org/2013/meeting/ldp/2013-10-28#resolution_2

Change ldp:container to ldp:containerResource.
See http://www.w3.org/2013/meeting/ldp/2013-11-04#resolution_4

Agree we can't re-introduce any default values and close ISSUE-81.
See http://www.w3.org/2013/meeting/ldp/2013-11-18#resolution_3

Arnaud Le Hors, 18 Nov 2013, 23:48:53

Display change log ATOM feed


Chair, Staff Contact
Tracker: documentation, (configuration for this group), originally developed by Dean Jackson, is developed and maintained by the Systems Team <w3t-sys@w3.org>.
$Id: 81.html,v 1.1 2015/08/17 04:43:12 denis Exp $