ISSUE-81

This page's sole purpose is to collect some various proposals around ISSUE-81 which looks to simplify some of the predicate names and how some of the features are modeled.

There are 3 samples (simple, inverse and indirect) to illustrate the proposals within context.

To start with, we'll address first only the proposed set of predicate names. You can express your preference on this different proposals via this poll: http://www.doodle.com/qf5am2pu89fcyaz2

After this, or even in coordination with this, we will decide on whether ldp:membershipObject is required.

1 Proposals -- New predicate names

<> a ldp:Container;
  ldp:membershipSubject <>;
  ldp:membershipPredicate rdf:member;
  ldp:membershipObject ldp:MemberSubject.

<> a ldp:Container;
  ldp:membershipSubject <>;
  ldp:membershipPredicateInverse skos:inScheme;
  ldp:membershipObject ldp:MemberSubject.

<> a ldp:Container;
  ldp:membershipSubject <>;
  ldp:membershipPredicate rdf:member;
  ldp:membershipObject foaf:primaryTopic .

<> a ldp:Container;
  ldp:membershipSubject <>; 
  ldp:membershipPredicate rdf:member;
  ldp:containerCreationBehaviorOnPOST ldp:insertNewInformationResource.

<> a ldp:Container;
  # Following indicates the object holds the container
  ldp:membershipObject <>;
  ldp:membershipPredicate skos:inScheme;
  ldp:containerCreationBehaviorOnPOST ldp:insertNewInformationResource.

<> a ldp:Container;
  ldp:membershipSubject <>;
  ldp:membershipPredicate rdf:member;
  ldp:indirectMemberPredicate foaf:primaryTopic;
  ldp:containerCreationBehaviorOnPOST ldp:insertNewInformationResource.

ldp:membershipSubject          --> (when membership in subject position; if membership is in object position, then ldp:membershipObject)
ldp:membershipPredicate       --> (unchanged)
ldp:membershipPredicateInverse --> (direction defined by ldp:membershipObject)
ldp:membershipObject           --> ldp:indirectMemberPredicate 

<> a ldp:Container;
  ldp:membershipContainerID <>; 
  ldp:membershipContainsRel rdf:member;
  ldp:membershipNewMemberID ldp:MemberSubject. </span>

<> a ldp:Container;
  ldp:membershipContainerID <>;
  ldp:membershipContainedByRel skos:inScheme;
  ldp:membershipNewMemberID ldp:MemberSubject. </span>

<> a ldp:Container;
  ldp:membershipContainerID <>;
  ldp:membershipContainsRel rdf:member;
  ldp:membershipNewMemberID foaf:primaryTopic .

ldp:membershipSubject          --> ldp:membershipContainerID
ldp:membershipPredicate       --> ldp:membershipContainsRel
ldp:membershipPredicateInverse --> ldp:membershipContainedByRel
ldp:membershipObject           --> ldp:membershipNewMemberID

<> a ldp:Container;
  ldp:container <>;
  ldp:containsRelation rdf:member;
  ldp:insertedContentRelation ldp:MemberSubject.

<> a ldp:Container;
  ldp:container <>;
  ldp:containedByRelation skos:inScheme;
  ldp:insertedContentRelation ldp:MemberSubject.

<> a ldp:Container;
  ldp:container <>;
  ldp:containsRelation rdf:member;
  ldp:insertedContentRelation foaf:primaryTopic .

ldp:membershipSubject          --> ldp:container
ldp:membershipPredicate       --> ldp:containsRelation
ldp:membershipPredicateInverse --> ldp:containedByRelation
ldp:membershipObject           --> ldp:insertedContentRelation 

<> a ldp:Container;
  ldp:memberAggregator <>;
  ldp:memberAggregationRelation rdf:member;
  ldp:memberObject ldp:MemberSubject.

<> a ldp:Container;
  ldp:memberAggregator <>;
  ldp:memberInverseAggregationRelation skos:inScheme;
  ldp:memberObject ldp:MemberSubject.

<> a ldp:Container;
  ldp:memberAggregator <>;
  ldp:memberAggregationRelation rdf:member;
 # Not sure how to identify which triple holds the member information in this proposal?
  ldp:?? foaf:primaryTopic .

ldp:membershipSubject & ldp:membershipObject --> ldp:memberAggregator
ldp:membershipPredicate --> ldp:memberAggregationRelation
ldp:membershipPredicateInverse --> ldp:memberInverseAggregationRelation

<> a ldp:Container;
  ldp:domainSelector <>;
  ldp:membershipPredicate rdf:member;
  ldp:rangeSelector ldp:MemberSubject.

<> a ldp:Container;
  ldp:domainSelector <>;
  ldp:membershipPredicateInverse skos:inScheme;
  ldp:rangeSelector ldp:MemberSubject.

<> a ldp:Container;
  ldp:domainSelector <>;
  ldp:membershipPredicate rdf:member;
  ldp:rangeSelector foaf:primaryTopic .

membershipSubject -> domainSelector (or maybe fromSelector, startSelector, originSelector ... )
membershipObject -> rangeSelector (or maybe toSelector, endSelector, destinationSelector ...)
membershipPredicate -> no change (?)
membershipPredicateInverse -> no change (?)

2 Proposals -- Part 1 (a)

The WG agreed upon John Arwe's proposal above with a goal to have something "better" than ldp:container as it is very close to ldp:Container.

Proposal is ldp:container => ldp:containingResource.

Here is some samples in context to help work it out. For me this predicate describes which resource the container is managing the membership predicates on. Which is a bit wordy, say ldp:managesMembershipTriplesFor <>, so ldp:containingResource seems like a nice compromise to me.

So we have:

 # Container and containing resource are the same (notice how this terminology/sentence uses the same words as the predicates...good)
 <> a ldp:Container; 
   ldp:container <>;
   ldp:containsRelation rdf:member;
   ldp:insertedContentRelation ldp:MemberSubject.

The thing that is odd is the resource <> is a ldp:Container and ldp:container points to itself. If we instead have:

 # Container and containing resource different 
 <assets/container> a ldp:Container;
   ldp:container <assets>;
   ldp:containsRelation rdf:member;
   ldp:insertedContentRelation ldp:MemberSubject.

To help test-drive the new predicate, it would be good to have within context of . So I like to use new terms in context to see how they work:

 # Container and containing resource are the same
 <> a ldp:Container;
   ldp:containingResource <>;
   ldp:containsRelation rdf:member;
   ldp:insertedContentRelation ldp:MemberSubject.

and then the other example:

 # Container and containing resource different
 <assets/container> a ldp:Container;
   ldp:containingResource <assets>;
   ldp:containsRelation rdf:member;
   ldp:insertedContentRelation ldp:MemberSubject.

3 Proposals -- Part I bis

This proposal is a suggestion for an improvement to build on top of whatever comes out of Part I. There are a few improvements proposed here:

• a making explicit of what the previous proposal is doing into pragmatic rules ( see: volunteering for the army which argues that these rules are not logical rules but causal/pragmatic ones: they specify what the user is comited to when posting to a LDPC )
• a simplification of the naming by moving the elements of the rule into a separate structure
• ldp:Containers need no longer specify these triples at all. In that case the only consequence of POSTing content to an LDPC ?ldpc is that { ?ldpc ldp:created ?member } where ?member is the name of the created resource.

The proposal is to not have 3 relations from the LDPC, but rather have 1 relation from the LDPC to a blank node which itself then has 3 relations.

<> a ldp:Container;
    ldp:creationRule [ ldp:subject <../card#me>;
                       ldp:predicate foaf:knows;
                       ldp:rangeSelector foaf:primaryTopic ] .

( note: the blank node could be given a URI. Would that allow reuse? )

The names for ldp:subject, ldp:predicate, ldp:rangeSelector, can be taken to be those people prefer in Part 1 above.

By default creation in an LDPC ?c of an LDPR ?r makes the following statement true:

 ?c ldp:created ?r .

The membershipRule is just the statement of a pragmatic consequence of creating a resource in that particular LDPC, or deleting a resource. There could be one or more such rules, and in particular the ldp:creationRule could be missing ( a vanilla server? ) This makes it easier to understand what the membershipXXX rules are about: they don't specify new membership predicates, but they specify a rule that makes it possible to deduce what happens when a resource is created: a number of other statements will be published as a consequence of the POST and are therefore something the POSTing agent is bound to when executing the POST.

It is extreemly important to specify that a client that does not understand the object of the ldp:creationRule NOT POST to that container!! ( see the use case described in the mail volunteering for the army )

The rule could be specified (but not necessarily in this spec) as an inclusion into a specific graph ( which one? ) of the result of the following query:

CONSTRUCT { ?subject ?pred ?obj }
FROM ?c
WHERE {
    ?c a ldp:Container;
       ldp:creationRule [ ldp:subject ?subject;
                            ldp:predicate ?pred;
                            ldp:rangeSelector ?selector ];
       ldp:created ?created .
    GRAPH ?created { ?created ?selector ?obj }
 } 

This does not I think have the problems of monotonicity that were found to be existing in the original ldp:membershipXXX relations.

4 Proposals -- Part II

(Updated based on WG selecting John Arwe's proposals):

1. Make ldp:insertedContentRelation optional

Its meaning is same as previous ldp:membershipObject. Omitting a triple with ldp:insertedContentRelation implies an object of ldp:MemberSubject (I haven't heard a proposal to change this name).

Clients can learn about the existence of this triple by requesting the non-member properties of the LDPC. If a server allows the object of this triple to be modified by a client, it is responsible for ensuring that the existing membership triples are updated to make the LDPC members valid with the new content relation.

Note: this depends on the LDPC server to have all the triples referred to by ldp:insertedContentRelation's object or be able to infer omitted triples.

See Issue-81