- From: Steve Speicher <sspeiche@gmail.com>
- Date: Mon, 17 Feb 2014 07:58:27 -0500
- To: Andrei Sambra <andrei.sambra@gmail.com>
- Cc: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
- Message-ID: <CAOUJ7JqabdJwxh5FYJRxC_-SVXoce-ix8eUghiHhzwePpLa4WQ@mail.gmail.com>
On Thu, Feb 13, 2014 at 9:53 AM, Andrei Sambra <andrei.sambra@gmail.com>wrote: > > On Wed, Feb 12, 2014 at 5:50 PM, Ashok Malhotra <ashok.malhotra@oracle.com > > wrote: > >> Right! >> 6.4.5 says that an LDPC can create an LDPC by using a Link header in the >> create request >> that specifies a LDPC. However, the link to 6.2.8 is not useful. So, >> some clarification >> is needed. >> >> There are also the related questions of "how do you create top-level >> LDPCs" i.e. how do >> you get started and how do you find all the top-level LDPCs contained in >> a server. >> Seems like we need a "mother of all containers" concept. >> All the best, Ashok >> > > Indeed. Moreover, as an implementer, I would also like to be able to > define the prefix for all resources created when POST-ing to an LDPC. This > is especially useful when clients have to create LDPCs that would in turn > create LDPRs. The way it currently works in RWW.IO is that all new LDPRs > have the "resource_" prefix, while new LDPCs have the "dir_" prefix. Since > this is far from a preferred solution, I would like to add an extra triple > to the parent LDPC, like in this minimal example of a bug tracker: > > <> a ldp:Container ; > dcterms:title "Bug tracker for project XYZ" ; > ldp:contains <bug_1>, <bug_2> ; > ldp:LDPRprefix "bug_" . > > I doubt this will make it into LDP 1.0, but it is something that is worth > investigating, since the spec doesn't mention any naming conventions when > creating new LDP(C,R)s. > Hi, I was treating this in my implementation as an implementation specific feature for the moment. I let the client give a hint [1] to what it wants but was planning (haven't implemented it yet) for container-specific prefixes. [1] - https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html#ldpc-post-slug - Steve Speicher > Best, > Andrei > > P.S. Apologies if this has already been discussed and I missed it. > > > >> >> On 2/12/2014 5:18 PM, Andrei Sambra wrote: >> >> Hi Ashok, >> >> >> On Wed, Feb 12, 2014 at 5:07 PM, Ashok Malhotra < >> ashok.malhotra@oracle.com> wrote: >> >>> Hi Andrei: >>> Take a look at section 6.4.5 and see if that answers your question. >>> All the best, Ashok >>> >> >> The links in section 6.4.5 point to section 6.2 which is about LDPC >> GET. Moreover, section 6.2 specifies that Link headers with rel=type are >> used in the HTTP response. The bottom line is that there is no mention of >> those headers being used during an HTTP request. I hope I've been clearer >> this time. >> >> -- Andrei >> >> >>> >>> On 2/12/2014 1:18 PM, Andrei Sambra wrote: >>> >>> Hi all, >>> >>> I'm getting really close to having a working implementation on RWW.IO[1]. However, I found that the spec section that describes POST behavior >>> for LDPCs lacks some details. More precisely, how should an LDP client >>> create containers within a container (details below). >>> >>> From section 6.4.5., we see that LDP servers that successfully create >>> a resource from a RDF representation in the request entity body must honor >>> the client's requested interaction model(s). More precisely, if the request >>> header specifies an LDPC interaction model, then the server must create an >>> LDPC. >>> >>> The link to the interaction model points to section 6.2.8, which deals >>> with GET requests -- exposing the Link header with rel=type. At this point, >>> one can only assume that the same Link header must be present during a >>> POST, since there is no mention in the spec about it. >>> >>> My suggestion would be to either add an example in section 6.4., or >>> explicitly mention that LDPRs and LDPCs can be created based on the Link >>> href value present in the POST request headers (either ldp:Resource or >>> ldp:Container). >>> >>> Best, >>> Andrei >>> >>> [1] https://www.w3.org/wiki/LDP_Implementations#RWW.IO >>> >>> >>> >> >> >
Received on Monday, 17 February 2014 12:58:55 UTC