W3C home > Mailing lists > Public > public-lod@w3.org > November 2010

Re: Status codes / IR vs. NIR -- 303 vs. 200

From: Nathan <nathan@webr3.org>
Date: Wed, 10 Nov 2010 21:09:27 +0000
Message-ID: <4CDB0A07.2030101@webr3.org>
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



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

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:29:51 UTC