RE: representing hypermedia controls in RDF

-public-lod (it's just about Hydra)

On Sunday, November 24, 2013 6:32 AM, Mark Baker wrote 
> On Thu, Nov 21, 2013 at 1:01 PM, Markus Lanthaler wrote:
> > +public-hydra
> >
> > On Thursday, November 21, 2013 5:11 PM, Mark Baker wrote:
> >> 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.

That's correct if the media type is specific enough but it doesn't hold at
all for generic media types such as JSON, XML, JSON-LD or Turtle... unless
of course you just provide a file/feed management API similar to WebDAV or
AtomPub. I'm not interested in those services. I'm interested in services
which need more details which are more or less all current Web APIs I'm
aware of. They typically expect very specific resource types that can't be
easily expressed in terms of media types without running into a
proliferation of media types.


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

hydra:expects specifies a class (note the capital "C" in "Comment"). So
hydra:expects tells the client that it expects an instance of the "Comment"
class in the example you are referring to. That Comment class then further
describes how instances look like by defining hydra:supportedProperties.



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

OK, I got it now but I have to think a bit more about it and its
consequences.. is this something you would like to propose for Hydra? Shall
I raise an issue?


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

In a sense, the Link construct is an optimization as well. Without it, the
only choice a client has it to blindly try to follow all IRIs. It is not
intended for access control.


--
Markus Lanthaler
@markuslanthaler

Received on Tuesday, 26 November 2013 11:42:03 UTC