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

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

From: Bradley Allen <bradley.p.allen@gmail.com>
Date: Wed, 10 Nov 2010 15:02:05 -0800
Message-ID: <AANLkTimn2u6tzzRkaq+c=ZBpQ9BfMeTzdFvTZw4TtoqT@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Sunday, 31 March 2013 14:24:30 UTC