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

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 21:32:17 UTC