- From: Nathan <nathan@webr3.org>
- Date: Wed, 10 Nov 2010 21:09:27 +0000
- To: Bradley Allen <bradley.p.allen@gmail.com>
- CC: Linked Data community <public-lod@w3.org>
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 21:10:34 UTC