ISSUE-88: Lost link to the resource created via POST
Lost link
Lost link to the resource created via POST
- State:
- CLOSED
- Product:
- Linked Data Platform Spec
- Raised by:
- Arnaud Le Hors
- Opened on:
- 2013-11-15
- Description:
- When ldp:insertedContentRelation is different from ldp:MemberSubject, the member of is not the resource that gets created on POST. The only way to find the resource is then ldp:created. However ldp:created is currently optional.
One solution is to make ldp:created mandatory when ldp:insertedContentRelation is different from ldp:MemberSubject. - Related Actions Items:
- No related actions
- Related emails:
- Re: ldp-ISSUE-89 (ldp:xyz): Tie the interaction model with the LDP data model through the notion of Managed Resources [Linked Data Platform Spec] (from henry.story@bblfish.net on 2013-11-20)
- Re: ldp-ISSUE-89 (ldp:xyz): Tie the interaction model with the LDP data model through the notion of Managed Resources [Linked Data Platform Spec] (from bertails@w3.org on 2013-11-18)
- Re: ldp-ISSUE-89 (ldp:xyz): Tie the interaction model with the LDP data model through the notion of Managed Resources [Linked Data Platform Spec] (from sspeiche@gmail.com on 2013-11-18)
- Re: ldp-ISSUE-89 (ldp:xyz): Tie the interaction model with the LDP data model through the notion of Managed Resources [Linked Data Platform Spec] (from henry.story@bblfish.net on 2013-11-18)
- ldp-ISSUE-89 (ldp:xyz): Tie the interaction model with the LDP data model through the notion of Managed Resources [Linked Data Platform Spec] (from sysbot+tracker@w3.org on 2013-11-18)
- Re: LDP Agenda for 18 November (from henry.story@bblfish.net on 2013-11-16)
- Re: LDP Agenda for 18 November (from henry.story@bblfish.net on 2013-11-16)
- ldp-ISSUE-88 (Lost link): Lost link to the resource created via POST [Linked Data Platform Spec] (from sysbot+tracker@w3.org on 2013-11-15)
Related notes:
This issue was also described in detail as "Missing Function from Object to LDPR member"
http://www.w3.org/2012/ldp/wiki/MembershipInferencing#missing_function_from_object_to_LDPR_member
There is another solution to this problem is to have LDPCs list all the ldp:member's explicitly.
There are then two ways of recovering the "membership properties:
1. either as something one can deduce from a "ldp:member" => "membership triple" rule
such as is expressed in the spec, but could be quickly condensed by a SPARQL rule such as
CONSTRUCT {
?subject ?relation ?object . //<- the consequence
} WHERE {
?ldpc ldp:membershipSubject ?subject;
ldp:membershipPredicate ?relation;
ldp:membershipObject ?memberRelation;
ldp:member ?resource . // <- a membership relation
GRAPH ?resource {
?resource ?memberRelation ?object .
}
}
http://www.w3.org/2012/ldp/wiki/MembershipInferencing#ldp:member_.3D.3E_membership_triples
(in which case the "membership triples" are optional
2. or if the "membership triples" are considered as causal consequences of POSTing to an LDPC which would be expressed by a rule such as the one listed below, then BOTH the ldp:member and the "membership triples" MUST be published.
ON POSTING TO ?ldpc
CREATING ?member
CONSTRUCT {
?subject ?relation ?object .
} WHERE {
GRAPH ?ldpc {
?ldpc ldp:membershipSubject ?subject;
ldp:membershipPredicate ?relation;
ldp:membershipObject ?memberRelation .
}
GRAPH ?member {
?member ?memberRelation ?object
}
}
Detailed wiki discussion for this issue is at:
http://www.w3.org/2012/ldp/wiki/Issue-88
Resolution: Close ISSUE-88 by making ldp:created mandatory when ldp:insertedContentRelation is different from ldp:MemberSubject
See http://www.w3.org/2013/meeting/ldp/2013-11-18#resolution_4Arnaud Le Hors, 18 Nov 2013, 23:44:13
Display change log