Re: Express "go to specific page" for a collection

On Thu, Jul 10, 2014 at 09:45:24AM +0200, Tomasz Pluskiewicz wrote:
> On Thu, Jul 10, 2014 at 8:43 AM, Philipp Zins <pipo@senaeh.de> wrote:
> >
> > A user interacts with the HTML document via links (anchors or buttons). They
> > know what they do, because they are labeled (e.g. "Buy now", "Click here to
> > login", "Close this window"). A good JSON hypermedia format has a similar
> > way to share vocabulary between server and client. Most formats seem to rely
> > on "rel" and Link Types for this (e.g. "next", "prev", "index", "help",
> > "edit"). I don't know if this is sufficient and I think this could be one of
> > the major advantages of JSON-LD (- using schema.org for common vocabulary
> > and Hydra for API-specific vocabulary). At least if I understand JSON-LD
> > correctly.
> This is because (every?) other hypermedia format defines not only the
> semantics but also the syntax. HAL is a bit better in this regard, but
> it introduces the "_embedded" property for example. This is very much
> like the media type nonsense. With Linked Data (and Semantic Web in
> general) you always speak about resources in an abstract way. It's the
> semantics that matter. JSON-LD, Turtle, RDF/XML are just syntax. Thus
> in Hydra you won't see mime types. Properties and operations are
> defined in terms of classes, ie. that an operation returns (an
> instance of) a specific class. Or requires an instance as input.
> 
> And so because Linked Data operates on a model, Hydra extends existing
> data rather than turn in upside-down. You can extend individual
> instances or their classes, because the format makes it possible. And
> so, yes, each instance can have its own link and operations.
> Furthermore if any Web API switched from Hydra to some other
> RDF-compatible hypermedia description the actual data will be
> unchanged. And so any client that ignores hypermedia would never
> notice the difference. With a move from HAL to SIREN all clients
> break, because the messages change completely.
> 
[...]
> I actually think that the term "hypermedia format" is not correct in
> terms of Hydra. There already is a format and its called RDF. In
> itself it is not enough for self-descriptive representations. However

Since Hydra is a melding of two worlds, REST/Hypermedia and RDF, we have
people coming to Hydra looking for a "hypermedia format" similar to many of
the perfunctory approaches to hypermedia right now. They are looking for
hypermedia controls, and not necessarily looking for a Linked Data (tm)
approach. However, to fully realize Fielding's vision of REST, in a
standard way, you really *need* Linked Data. 

Markus (et al.), do you think it would be important to address this (early)
in the spec so that people evaluating Hydra looking for a hypermedia format
can be "converted" instead of prematurely dismissing it simply because it
is built on (scary) RDF? Tomasz' response here would be a good starting
point.

> Hydra is not a new format. Nor does it change RDF in any way. It is
> merely an extension, which allows augmenting existing data with
> description of hypermedia controls.

This is one of the most succint definitions of Hydra that I have come
across. Thanks, Tomasz! It is a lot simpler to understand Hydra if you
look at it from an RDF perspective.

-- 
Chris

Received on Monday, 25 August 2014 18:25:17 UTC