- From: Bradley Allen <bradley.p.allen@gmail.com>
- Date: Wed, 10 Nov 2010 15:02:05 -0800
- To: nathan@webr3.org
- Cc: Linked Data community <public-lod@w3.org>
I'm not making a distinction between HTML and RDF/XML files in this discussion, as either can be containers of RDF statements about resources. If I want to use REST as a way to update statements about an NIR named with a fragment URI using whatever serialization, since I can only update slash URIs then there is some machinery or pattern in place that allows you to determine what slash URI to use to update the statements. What I'm looking for what you do to make that unproblematic. Bradley P. Allen http://bradleypallen.org On Wed, Nov 10, 2010 at 2:00 PM, Nathan <nathan@webr3.org> wrote: > Please tell me that you're not trying to infer that using the HyperText > Transfer Protocol to update an HTML document which describes the staff in a > staff-of-three company, similar to the following, is RESTful: > > http://example.org/staff#mary > http://example.org/staff#bob > http://example.org/staff#bill > == PUT http://example.org/staff > > But updating an RDF document, for the same company, containing the same > descriptions, of the same three people, identified by the same three URIs, > is somehow un-RESTful: > > http://example.org/staff#mary > http://example.org/staff#bob > http://example.org/staff#bill > == PUT http://example.org/staff > > Or are you saying that updating a description of one person, (supposedly) > identified by the URI http://example.org/people/sue, is RESTful: > > PUT http://example.org/people/sue > > but updating a description of one person, identified by the URI > http://example.org/people/sue#me, is un-RESTful: > > PUT http://example.org/people/sue > > ps: I use fragments, and update descriptions RESTfully, never ever had a > problem yet. > > Regards, > > Nathan > > Bradley Allen wrote: >> >> The assumption then would be that each representation would in the >> limit have a corresponding fragment URI. Correct? >> >> Bradley P. Allen >> http://bradleypallen.org >> >> >> >> On Wed, Nov 10, 2010 at 1:09 PM, Nathan <nathan@webr3.org> wrote: >>> >>> exactly the same way, you GET,PUT,POST,PATCH,DELETE descriptions.. >>> >>> PUT /resource1 >>> >>> unless of course you mean, if I have 100,000 concepts described by a >>> single >>> representation, how do I update it RESTfully, in which case the answer is >>> clearly, don't put 100,000 concepts in a single representation. >>> >>> as in, do things exactly the same way you do now, whatever works for you >>> - >>> using a fragment has no bearing on anything REST-related, unless as I >>> say, >>> you decide it's a good idea to drop a full db/store in to one >>> representation >>> (which I'd suggest isn't a good idea!) >>> >>> ps: PATCH isn't the best idea unless you've got some good skolemization >>> >>> Best, >>> >>> Nathan >>> >>> Bradley Allen wrote: >>>> >>>> Nathan- I guess I'm not being clear about my problem. How do you get a >>>> REST API to work with fragment URIs? - BPA >>>> >>>> Bradley P. Allen >>>> http://bradleypallen.org >>>> >>>> >>>> >>>> On Wed, Nov 10, 2010 at 12:33 PM, Nathan <nathan@webr3.org> wrote: >>>>> >>>>> Bradley Allen wrote: >>>>>> >>>>>> Nathan- I think you are overly discounting scalability problems with >>>>>> fragment URIs. >>>>>> >>>>>> Most of the use cases I am dealing with in moving linked data into >>>>>> production at Elsevier entail SKOS concept schemes with concepts >>>>>> numbering in the 100,000's to millions, which will be constantly under >>>>>> curation, preferably using REST APIs that allow POSTs and PUTs to >>>>>> create and update individual concepts. >>>>>> >>>>>> Can you articulate a reasonable way in which that can be accomplished >>>>>> using fragment URIs? - regards, BPA >>>>> >>>>> /resource1 >>>>> /resource2 >>>>> /resource3 >>>>> >>>>> /resource1#1 >>>>> /resource2#2 >>>>> /resource3#3 >>>>> >>>>> with the additional benefit that you can do >>>>> >>>>> /resourcea#1 >>>>> /resourcea#2 >>>>> /resourceb#1 >>>>> /resourceb#2 >>>>> >>>>> as in, exactly the same way, but with *more* options. >>>>> >>>>> >>>> >>> >> >> > >
Received on Wednesday, 10 November 2010 23:02:38 UTC