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

On 25 Aug 2014 at 20:24, Chris Chapman wrote:
> 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.

Yes, definitely.


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

If you know RDF, yes :-)


A while ago, I wrote a paper targeted to people with RDF background. Given
your statement above, you might find it interesting as well (even though
it's obviously not up to date anymore):

   http://m.lanthi.com/ldow2013-paper


Cheers,
Markus


--
Markus Lanthaler
@markuslanthaler

Received on Thursday, 4 September 2014 10:45:48 UTC