Re: representing hypermedia controls in RDF

Hi Ruben,

On Fri, Nov 22, 2013 at 5:01 AM, Ruben Verborgh <ruben.verborgh@ugent.be> wrote:
> Alternatively, we could learn from http://tools.ietf.org/html/rfc2616#section-9.5 to define standard operations:
>
>> POST is designed
>>    to allow a uniform method to cover the following functions:
>>
>>       - Annotation of existing resources;
>>
>>       - Posting a message to a bulletin board, newsgroup, mailing list,
>>         or similar group of articles;
>>
>>       - Providing a block of data, such as the result of submitting a
>>         form, to a data-handling process;
>>
>>       - Extending a database through an append operation.
>
> CreateResourceOperation covers the second thing here.

Sure, but that's not part of the interface to the service so out of
scope IMO. The method is POST which defines the contract between
client and server. Though the server may only implement one of those
things above, that's an implementation detail that the more generic
POST interface hides from the client.

I'm reminded of our HTTP DELETE disagreement in LDP. I suspect we've
bumped up against that one again :P

>> Also, the next version of RDF Forms has been sitting in my head for a
>> few years after collecting a little bit of experience with the current
>> version. One of the big changes I would make is to go fully predicate
>> based rather than class based simply because I expect it would be more
>> flexible and also fit better into, e.g. HTML or the Link header. So if
>> I had a POST-accepting resource, instead of this:
>>
>> <http://example.org/res1> a hydra:CreateResourceOperation .
>>
>> I'd go with;
>>
>> <> hydra:sink <http://example.org/res1> .
>
> But how do you further annotate the “operation” then?

In that case, "sink" is defined to imply POST. For other methods,
there'd have to be a way to connect a predicate to a method. A simple,
though aesthetically unsatisfying approach, would be to use the
methods as predicates;

<> <http://www.iana.org/assignments/http-methods#POST>
<http://example.org/res1> .

On Fri, Nov 22, 2013 at 5:01 AM, Ruben Verborgh <ruben.verborgh@ugent.be> wrote:
> [moved from public-lod to public-hydra]
>
> Hi Mark,
>
>> And POST can be
>> used for much more than creation, so I think "CreateResourceOperation"
>> is a misnomer (or else overly specific).
>
> I guess people can create their own operations, right?
> Such as IncrementCounterOperation.
>
> To capture the semantics of those operations, further description mechanisms could be used.
> (But they might require switching to a language with more expressive power, to use quantification.)
>
> Alternatively, we could learn from http://tools.ietf.org/html/rfc2616#section-9.5 to define standard operations:
>
>> POST is designed
>>    to allow a uniform method to cover the following functions:
>>
>>       - Annotation of existing resources;
>>
>>       - Posting a message to a bulletin board, newsgroup, mailing list,
>>         or similar group of articles;
>>
>>       - Providing a block of data, such as the result of submitting a
>>         form, to a data-handling process;
>>
>>       - Extending a database through an append operation.
>
> CreateResourceOperation covers the second thing here.
>
>> Also, the next version of RDF Forms has been sitting in my head for a
>> few years after collecting a little bit of experience with the current
>> version. One of the big changes I would make is to go fully predicate
>> based rather than class based simply because I expect it would be more
>> flexible and also fit better into, e.g. HTML or the Link header. So if
>> I had a POST-accepting resource, instead of this:
>>
>> <http://example.org/res1> a hydra:CreateResourceOperation .
>>
>> I'd go with;
>>
>> <> hydra:sink <http://example.org/res1> .
>
> But how do you further annotate the “operation” then?
>
> Best,
>
> Ruben

Received on Sunday, 24 November 2013 16:10:13 UTC