Re: representing hypermedia controls in RDF

On Thu, Nov 21, 2013 at 1:01 PM, Markus Lanthaler
<markus.lanthaler@gmx.net> wrote:
> +public-hydra
>
> On Thursday, November 21, 2013 5:11 PM, Mark Baker wrote:
>> Cool. Very similar to RDF Forms in important ways, though I think RDF
>> Forms internalizes some useful features that Hydra could benefit from;
>> stripping out information that isn't required (or isn't an
>> optimization) for a state transition, e.g. DeleteResourceOperation.
>
> Right, we already discussed removing all those prefided *ResourceOperations.
> The only reason I included them in the first place was to bootstrap the
> "system" so that developers could build simple CRUD-based systems without
> having to define these things themselves. This is ISSUE-5 [1] btw. :-)

Yep, I started down that path too. Then I had to use it :)

>
>> PUT should also be usable without any required parameterization,
>
> Not so convinced about that..

It's a relatively minor point, but the idea there is that the common
case will involve retrieving a representation, modifying it, then
PUTting it back. Obviously the media type of initially retrieved
representation is all you need in that case. Not to suggest it's the
only case, though, so I'm all for non-authoritative optimizations.

>> though declaring an accepted media type (something that seems to be
>> missing from hydra)
>
> Right.. Hydra currently assumes the client uses the media type it used to
> retrieve the API documentation or the entry point for its requests. This
> leaves binaries out, I know. It isn't currently specified but I think that
> could be handled by specific classes together with hydra:expects as well.

I haven't quite figured out hydra:expects. The examples show that it's
something other than a media type, and moreover, something (e.g.
"comment") which I'd normally use a predicate/rel for.

>> can be considered an optimization. And POST can be
>> used for much more than creation, so I think "CreateResourceOperation"
>> is a misnomer (or else overly specific).
>
> Of course.. that's the whole reason that Operations thing exists in the
> first place. But it isn't Hydra's job to define them. Concrete APIs will
> create their own by subclassing Operation (or one of the three others unless
> we remove it).

Ok.

>
>
>> 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> .
>>
>> (yah, that example represents at least 3 improvements I'd suggest for
>> the language - sorry if it's too dense)
>
> Indeed. I don't understand that example at all. Could you explain it a bit
> more in detail?

Well, the most important difference is the use of the predicate. The
intent there is that if you consider the two resources in play - the
one containing the form/affordances, and the one receiving the data
that results from the form being used - then they share a generic
relationship which can be called a "sink", aka "The second resource
acts as a sink for data that emerges as a result of the affordances in
the first being followed". So "sink" is 1-to-1 with HTTP POST, and
would of course require additional parameterization, but that's the
gist. For documents containing multiple forms, I guess you'd want a
subject that wasn't the document itself, but some identifier for the
form; and you'd also need that same id to hook the parameters to, obv.

> [1] https://github.com/HydraCG/Specifications/issues/5

We may or may not need one depending how we connect parameterization
to operations after the required decisions surrounding them have been
mode. Obviously we need to support parameterized GET requests though.

And FWIW, I don't like the "Link" construct. If the publisher doesn't
want me to crawl some particular subset of their URI space, they
should describe that space in robots.txt.

Received on Sunday, 24 November 2013 05:32:38 UTC