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 <[email protected]> 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.
