Hypermedia and Linked Data [was: Thoughts and opinions on hypermedia API]

[mca]

Martynas:

I started a new thread for this one...

I'll state my POV on this (rather vague) topic and see what transpires.

The Linked Data Platform is actually a W3C spec[1]. There is no "hypermedia" spec (and there never will be).

Linked Data Principles[2]  are (per @timbl) "expectations of behavior." Hypermedia is not about behavior.

Hypermedia has been around a *long* time. Ted Nelson coined the term[3] and it was implemented[4] long before we had HTTP & HTML.

I think the best description of hypermedia|hypertext is this one from @fielding:

"When I say Hypertext, I mean the simultaneous presentation of information and controls such that the information becomes the affordance through which the user obtains choices and selects actions"[5] (there are some other good refs in that blog post, too)

Finally, "hypermedia" is a terchnique, a tool. It can be applied in lots of places (including LDP). So asking the diff between hypermedia and LDP is like asking the diff between Swedish modern furniture and a woodsaw; a category error.

Having said all that, this group was created to talk about the tool in all it's places and forms. Talking about the hypermedia aspects of LDP is certainly a valid topic here. 

Cheers.

[1] http://www.w3.org/TR/ldp/

[2] http://www.w3.org/DesignIssues/LinkedData.html

[3] http://en.wikipedia.org/wiki/Ted_Nelson

[4] http://en.wikipedia.org/wiki/HyperCard#History

[5] http://amundsen.com/blog/archives/1109

mca

+1.859.757.1449
skype: mca.amundsen
http://amundsen.com/blog/
http://twitter.com/mamund
https://github.com/mamund
http://www.linkedin.com/in/mamund

---------- Forwarded message ----------
From: Martynas Jusevičius <mart...@graphity.org>
Date: Sat, Oct 26, 2013 at 7:00 PM
Subject: Re: Thoughts and opinions on hypermedia API
To: hyperme...@googlegroups.com


Hey all,

don't want to start a flame, but can you explain the relationship
between Hypermedia and Linked Data (Platform) to me? And what is
Hypermedia supposed to achieve?
Because most of the things you are discussing about are defined in
RDF, Linked Data principles, and also in the LDP spec (which I'm not a
fan of).

Martynas
graphityhq.com

[Mike Kelly]

Semweb/LPD is basically a hypermedia system. It's pretty convoluted
because it tries to make _everything_ (i.e. resource state, as well as
resource relationships) into machine-readable graphs. The idea is that
by meticulously specifying and building these graphs of data and
relationships that something significant will emerge. It's been almost
10 years, and I would say we're still all waiting for that to happen.

At some point you have to draw a line where machines hand off control
to the people programming them. It's not clear to me where (if at all)
semweb draws a line, but - afaict - it's not early enough to prevent
most people giving up and looking for a simpler approach that's a
little less "adventurous".

Cheers,
M

> --
> You received this message because you are subscribed to the Google Groups
> "Hypermedia Web" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to hypermedia-we...@googlegroups.com.
> To post to this group, send email to hyperme...@googlegroups.com.
> Visit this group at http://groups.google.com/group/hypermedia-web.
> For more options, visit https://groups.google.com/groups/opt_out.



--
Mike

http://twitter.com/mikekelly85
http://github.com/mikekelly
http://linkedin.com/in/mikekelly123

[Martynas Jusevičius]

Hey Mike,

I don't buy your "convoluted" argument. It's like saying that the
original World Wide Web (of documents) was convoluted because the
browsers only rendered HTML as hypertext, and not plain text files or
some proprietary formats.

I'm quite certain that interoperability needs a common representation
data model. On the Web of documents it was HTML, on the Semantic Web
of data it's RDF. It has taken some time because important standards
like SPARQL 1.1 were only published this year, but now the interesting
part starts.

Martynas
graphityhq.com

[Mike Kelly]

On Mon, Oct 28, 2013 at 1:13 PM, Martynas Jusevičius
<mart...@graphity.org> wrote:
> Hey Mike,
>
> I don't buy your "convoluted" argument. It's like saying that the
> original World Wide Web (of documents) was convoluted because the
> browsers only rendered HTML as hypertext, and not plain text files or
> some proprietary formats.

Have you seen the JSON-LD spec? If you line that up against CJ, HAL,
etc. you start to get an idea of what I'm talking about.

> I'm quite certain that interoperability needs a common representation
> data model. On the Web of documents it was HTML, on the Semantic Web
> of data it's RDF.

And on the "non-Semantic" Web of data and services (i.e. the web API
ecosystem) it's mostly just plain json and xml. So why is this still
the case if RDF serialisations are not convoluted and produce
significantly better systems?

> It has taken some time because important standards
> like SPARQL 1.1 were only published this year, but now the interesting
> part starts.

I'm highly skeptical about the idea that semweb is going to benefit
from _even more_ standards. This "we're just on the verge of something
great" thing seems to have been the semweb narrative for quite a while
now.

Cheers,
M

[Emil Chacko]

Mike:

 Finally, "hypermedia" is a terchnique, a tool. It can be applied in lots of places (including LDP). So asking the diff between hypermedia and LDP is like asking the diff between Swedish modern furniture and a woodsaw; a category error.

I don't have much idea about linked data .But from the little understanding .It seems to me that hypermedia specs like collection+json or HAL is a constrained data structure from which the client has to infer the semantics .I was wondering if semantics is what we really want is it possible to achieve the same loose coupling using semantic data . 

An analogy for better clarity can be thought of like putting apples,oranges in bag named apples,oranges vs apples/oranges self identifying itself . 

[Ruben Verborgh]

Hi Emil,

> I was wondering if semantics is what we really want is it possible to achieve the same loose coupling using semantic data .

Yes, and the Hydra Core Vocabulary is a good way to achieve that.

The limitation of HAL etc. is that their semantics are purely structure-based;
Hydra's semantics are defined with the underlying Semantic Web technologies.
This allows more flexibility in how they are used (at the expense of more complex clients),
and also allows combination with other types of hypermedia controls and Linked Data.

Personally, I think specific media types for hypermedia are a dead end anyway
(see https://ruben.verborgh.org/articles/fine-grained-content-negotiation/).
Linked Data formats are compatible with multiple content and hypermedia vocabs.

Best,

Ruben

[Emil Chacko]

Ruben ,

 Thanks for your phd thesis and for writing it in a simple to read manner.Loved your thesis .I just read some chapters of it,that how I got a vague idea of semantics and linkeddata .

[Mike Kelly]

On Wed, Feb 22, 2017 at 11:09 AM, Ruben Verborgh <Ruben.V...@ugent.be> wrote:

The limitation of HAL etc. is that their semantics are purely structure-based;
Hydra's semantics are defined with the underlying Semantic Web technologies.

Eh?

 

This allows more flexibility in how they are used (at the expense of more complex clients),
and also allows combination with other types of hypermedia controls and Linked Data.

Could you be more specific about these benefits?

[Ruben Verborgh]

Hi Mike,

>> The limitation of HAL etc. is that their semantics are purely structure-based;
>> Hydra's semantics are defined with the underlying Semantic Web technologies.
>
> Eh?

HAL is based on a JSON structure.
RDF formats can convey the same meaning with different structures.
This is an observation, not a quality judgement (yet—see below).

For an example, try conneg on http://data.linkeddatafragments.org/viaf
with different MIME types such as:
– text/html
– text/turtle
– application/trig
– application/json
– application/ld+json
You will recognize the same hypermedia controls in different structures.

> Could you be more specific about these benefits?

The message format is much more extensible.
You can combine different types of data in there,
and also use different kinds of hypermedia controls.

For instance, some clients of my API only support links,
other clients support the exact three-field form
that I'm using in the representation above,
other clients support generic Hydra forms.
Real clients BTW, not hypothetical ones.

RDF-based formats have infinite dimensions
of combinability and extensibility
(again, at the cost of more complex clients).
The features of HAL, Collection+JSON, and dozens of others
are not necessarily combinable in one media type
without resorting to XKCD 927.

More about this here:
https://ruben.verborgh.org/blog/2015/10/06/turtles-all-the-way-down/

Best,

Ruben

[Mike Kelly]

On Wed, Feb 22, 2017 at 12:42 PM, Ruben Verborgh <Ruben.V...@ugent.be> wrote:

Hi Mike,

>> The limitation of HAL etc. is that their semantics are purely structure-based;
>> Hydra's semantics are defined with the underlying Semantic Web technologies.
>
> Eh?

HAL is based on a JSON structure.
RDF formats can convey the same meaning with different structures.
This is an observation, not a quality judgement (yet—see below).

For an example, try conneg on http://data.linkeddatafragments.org/viaf
with different MIME types such as:
– text/html
– text/turtle
– application/trig
– application/json
– application/ld+json
You will recognize the same hypermedia controls in different structures.

HAL's underlying processing model (root resource, links, embedded resources) can be rendered into multiple formats. I used to maintian the XML specification but stopped and it's since been resurrected in a separate I-D. I even proposed a way of rendering the HAL model in HTML.

> Could you be more specific about these benefits?

The message format is much more extensible.
You can combine different types of data in there,
and also use different kinds of hypermedia controls.

For instance, some clients of my API only support links,
other clients support the exact three-field form
that I'm using in the representation above,
other clients support generic Hydra forms.
Real clients BTW, not hypothetical ones.

HAL has had multiple extensions built on top of it e.g. hal-forms that mamund has worked on. Cj also has extensions.

 

RDF-based formats have infinite dimensions
of combinability and extensibility
(again, at the cost of more complex clients).

I think after 20 years of flogging this dead horse, rebranding to LinkedData, etc... I think the RDF community should concede that they might have got this cost-benefit equation wrong and that having "infinite dimensions" is a bug and not a feature of their proposed architecture.

 

The features of HAL, Collection+JSON, and dozens of others
are not necessarily combinable in one media type
without resorting to XKCD 927.

The butt of that joke is the guy proposing that combining the standards was necessary.

I would never propose that; the same way I wouldn't ever replace my toolbox with one universal saw-hammer-wrench-screwdriver tool. I'm fine using each one for the job they're designed for.

It strikes me that this assumed need for universality is exactly the downfall of RDF. The semweb community has tried to build a web that's so machine readable it's barely human.. and unfortauntely the really tough bits of distributed systems are people problems.

Afaict; most people are fine spending 5 man-weeks on creating and maintaining the transformation logic that maps divergent data structures together, rather than 5 years developing the perfect ontology.

Cheers,

M

[Ruben Verborgh]

Hi Mike,

> HAL's underlying processing model (root resource, links, embedded resources) can be rendered into multiple formats. I used to maintian the XML specification but stopped and it's since been resurrected in a separate I-D. I even proposed a way of rendering the HAL model in HTML.

Indeed, and these need to be defined again and separately
by each format such as HAL.

A proposal would be to make HAL an IETF/W3C standard
so that we can build on it reliably and in a standard way;
ad-hoc extensions lead to a brittle ecosystem.

> HAL has had multiple extensions built on top of it e.g. hal-forms that mamund has worked on. Cj also has extensions.

Of course, but the problem there is "on top of HAL".
Features can't be developed and combined separately.

> I think after 20 years of flogging this dead horse, rebranding to LinkedData, etc...

Let's stick to technical arguments.

I say that it is possible with RDF and argue why this is useful for many use cases.
I'm not saying that anyone should convert to RDF, just showing benefits if they do.

> having "infinite dimensions" is a bug and not a feature

But that's exactly what the (human) Web offers us,
and what I want to offer to automated clients as well.

On a technical level, I'm curious then how you'd handle
https://ruben.verborgh.org/articles/fine-grained-content-negotiation/.

> The butt of that joke is the guy proposing that combining the standards was necessary.

We can all extend HAL, but we'll end up with a dimensionality problem
(and we'd need a standardized HAL first).

Hypermedia is by nature a very flexible thing;
one-dimensional extensibility is too limited
for the types of clients that I aim to build
(see previous pointers plus https://arxiv.org/pdf/1609.07108v1.pdf).

Best,

Ruben

[Jeff Michaud]

Hello Ruben,

I have a tendency to align with Mike K. on this. I think that the semantic web, although seeming to appear to be the "correct next step" also appears to dip unfathomably deep into and abyss of complexity, inherent to it's subject (run-time semantic agreement and consumption). This seems to be floating right around the edge of what's fathomable from a human standpoint. Heck, "run-time semantic agreement and consumption" is something that even humans struggle with when communicating amongst themselves.

And as I've exposed in a different thread, the inflection point where this semantic complexity starts to blossom, in association with hypermedia, seems to be exactly where the browser sat and no further. This yielded a very powerful platform for humans to play into and I think that more of this is possible if we leverage this inflection point further and hand-off semantic handling to humans (e.g. see HCLI [1]).

[1] https://github.com/cometaj2/I-D/blob/master/hcli/draft-michaud-hcli-00.txt

Regards
Jeff Michaud

[Ruben Verborgh]

Hi Jeff,

> I think that the semantic web, although seeming to appear to be the "correct next step"

It definitely makes sense on the level of integration.
Take GraphQL and add "across multiple API’s"
and you essentially get SPARQL (or a reinvention of it).

> also appears to dip unfathomably deep into and abyss of complexity

You don't have to import the whole stack;
start with the bits that make sense.

> (run-time semantic agreement and consumption).

But that's what makes hypermedia exciting, no?

We're well past SOAP technologically;
finally adopting a runtime mindset for hypermedia
enables much more exciting integrations.

We can keep on building one-dimensional one-offs
and do all the integration work with manual development,
or we can actually use hypermedia at runtime.
But yes, then we're talking about a new generation of clients.
Much of the rest is just RPC in disguise
(and that's fine, but we should be clear about that).

> This seems to be floating right around the edge of what's fathomable from a human standpoint.

That's quite alright if we start with simple pieces
(cfr. https://arxiv.org/pdf/1609.07108v1.pdf).

> (e.g. see HCLI [1]).

Makes me think of the Hydra Console; cool.
Same concern about extensibility though.

Best,

Ruben

[Jeff Michaud]

On Monday, February 27, 2017 at 6:25:20 AM UTC-8, Ruben Verborgh wrote:

Hi Jeff,

> I think that the semantic web, although seeming to appear to be the "correct next step"

It definitely makes sense on the level of integration.
Take GraphQL and add "across multiple API’s"
and you essentially get SPARQL (or a reinvention of it).

> also appears to dip unfathomably deep into and abyss of complexity

You don't have to import the whole stack;
start with the bits that make sense.

> (run-time semantic agreement and consumption).

But that's what makes hypermedia exciting, no?

We're well past SOAP technologically;
finally adopting a runtime mindset for hypermedia
enables much more exciting integrations.

We can keep on building one-dimensional one-offs
and do all the integration work with manual development,
or we can actually use hypermedia at runtime.
But yes, then we're talking about a new generation of clients.
Much of the rest is just RPC in disguise
(and that's fine, but we should be clear about that).

I guess I'm not talking about hypermedia per say. In my mind, hypermedia (i.e. hypertext) is a platform on which folks are attempting to build machine understandable semantic web. I personally find more exciting the prospect of serving humans by giving them powerful new tools, similar to the browser, to let them explore new horizons (e.g. by bridging gaps between architectural styles, like HCLI is attempting to do). :).
 

> This seems to be floating right around the edge of what's fathomable from a human standpoint.

That's quite alright if we start with simple pieces
(cfr. https://arxiv.org/pdf/1609.07108v1.pdf).

I don't disagree with what you write and my thoughts seem to be somewhat aligned with yours there (and this is exactly where HCLI is standing; It's a reusable semantic interface). What you describe also somewhat reminds me of what standard link relations help us accomplish.
 

> (e.g. see HCLI [1]).

Makes me think of the Hydra Console; cool.
Same concern about extensibility though.

Thanks for bringing the Hydra Console to attention; I wasn't aware of it. I think that HCLI differs significantly in its objective and direction of thought from the Hydra Console however. HCLI is an attempt at a bridge between two very powerful styles (REST and pipe and filter).

Cheers,
Jeff Michaud
 

Best,

Ruben