- 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>
+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:32 UTC