W3C home > Mailing lists > Public > public-hydra@w3.org > November 2013

RE: representing hypermedia controls in RDF

From: Markus Lanthaler <markus.lanthaler@gmx.net>
Date: Thu, 21 Nov 2013 19:01:55 +0100
To: "'Mark Baker'" <distobj@acm.org>
Cc: "'Linked Data community'" <public-lod@w3.org>, <public-hydra@w3.org>
Message-ID: <017b01cee6e3$c46cc370$4d464a50$@lanthaler@gmx.net>
+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. :-)


> PUT should also be usable without any required parameterization,

Not so convinced about that..


> 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.


> 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).


> 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?


> I have some other thought similar to Ruben's too. But I've gone ahead
> and joined the group, and once I'm caught up on the discussion to
> date, we can discuss this further over there.

Awesome! Welcome on board :-)


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



--
Markus Lanthaler
@markuslanthaler
Received on Thursday, 21 November 2013 18:02:35 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:29:40 UTC