RE: representing hypermedia controls in RDF

+public-hydra since there are a couple of things which we should look at
there as well

On Thursday, November 21, 2013 3:03 PM, Ruben Verborgh wrote:
> >> - representing hyperlinks in RDF (in addition to subject/object
> >>   URLs)
> >
> > hydra:Resource along with hydra:Link covers that:
> > http://bit.ly/1b9IK32
> 
> And it does it the way I like: resource-oriented!
> 
> Yet, the semantic gap I need to bridge is on the level of predicates.
> None of the Hydra properties [1] have hydra:Link as range or domain.
> So how to connect a link to a resource?

Right, nothing has hydra:Link as range because it's a specialization of
rdf:Property. The range would need to be hydra:Resource.

Typically you would define your link relations, aka predicates, to express
the semantic relationship between the two resources. If you want such a
predicate to become a hypermedia affordance, you type it as hydra:Link
instead of rdf:Property:

  vocab:homepage a hydra:Link .

  <a> vocab:homepage <b>

That way even clients that know nothing about vocab:homepage will be able to
find out that it is a link relation and that <b> is expected to be
dereferenceable. The spec doesn't include any entailments yet (to not scare
too many people away at this stage) but they would be

  xxx a hydra:Link .
  aaa xxx bbb .

  ==> bbb a hydra:Resource .


> More or less like:
> <a
> href="http://en.wikipedia.org/wiki/Daft_Punk">http://dbpedia.org/resour
> ce/Daft_Punk</a>
> On the human Web, we do this all the time:
> <a href="http://en.wikipedia.org/wiki/Daft_Punk">Daft Punk</a>
> The difference of course with the Semantic Web is that the identifiers
> need to be URIs, not labels.

Right. Hydra provides a framework to define such things. It (currently)
doesn't define a predicate for untyped hyperlinks because I believe they
generally don't make much sense in a m2m context. Nevertheless, it may make
sense to define something for very simple use case (crawlers) or to be able
to express, e.g., links extracted from a HTML page.

I raised ISSUE-15 [1] to keep track of this.


> I guess a seeAlso would do, (but then again, seeAlso probably applies
> to anything):
> dbpedia:Daft_Punk rdfs:seeAlso wikipedia:Daft_Punk.
> 
> However, I really want something stronger here.
> But perhaps usual hyperlinks are not interesting enough,
> as they can actually be represented as predicates (= typed links):
> 
> dbpedia:Daft_Punk :hasArticle wikipedia:Daft_Punk.

Right, but nothing here tell's you whether wikipedia:Daft_Punk is just an
identifier or a hyperlink. If you type wikipedia:Daft_Punk as hydra:Resource
or :hasArticle as hydra:Link it becomes explicit.



> >> - representing URI templates [2]
> > It's covered by hydra:IriTemplate: http://bit.ly/1e2z2NW
> 
> Now this case is much more interesting than simple links :-)
> 
> Same semantic problem for me though:
> what predicates do I use to connect them to my resource?
> For instance:
> 
> </users> :membersHaveTemplate :UsersTemplate.
> :UsersTemplate a hydra:IriTemplate;
>                          hydra:template "/users/{userid}".

Well, same thing in principle

  :membersHaveTemplate a hydra:TemplatedLink .

Of course Hydra can't know what :membersHaveTemplate really *means*, i.e.,
in which relationship the two resource stand. It just allows you to tell a
client that it's values are link templates and that you can use them to
construct URLs which lead you to things that are of type hydra:Resource


> So what I actually need is the equivalent of hydra:members,
> but then with a template as range.
> Should we discuss take this to the Hydra list? I'd be interested!

Definitely.. I already CCed public-hydra. We should move the discussion
there as it is quite specific to hydra.


> (Also, have you considered hydra:template's range as something more
> specific than xsd:string?)

No, I'm not aware of any type representing RFC6570 IRI templates and didn't
see the need to complicate Hydra by defining one :-)


> >> - representing forms (in the HTML sense)
> > In Hydra this is done by a combination of hydra:Operation,
> hydra:expects and
> > hydra:supportedProperties, see http://bit.ly/17t9ecB
> 
> I like example 10 in that regard, but I'm stuck at predicates again:
> how to connect the Link to the resource it applies to?

I'm not sure I understand your question. Example 10 defines the property
http://api.example.com/doc/#comments You can then simply use it in your data

  @prefix api: <http://api.example.com/doc/#> .

  </> api:comments </comments/> .

The client can lookup what api:comments is. It will find out that it is a
hydra:Link, so it represents a hyperlink. Furthermore, it will see that it
can create new comments by POSTing a api:Comment to /comments/.

Have you seen the issue tracker demo on my homepage?

  http://bit.ly/15i8rpp

If you go to the entrypoint there's a JSON property "issues". If you move
the mouse over it you'll see that it expands to vocab:EntryPoint/issues if
you dereference that URL [2] you'll get its definition:

{
  "@id": "vocab:EntryPoint/issues",
  "@type": "hydra:Link",
  "label": "issues",
  "description": "The collection of all issues",
  "domain": "vocab:EntryPoint",
  "range": "http://purl.org/hydra/core#Collection",
  "supportedOperations": [
    {
      "@id": "_:issue_create",
      "method": "POST",
      "label": "Creates a new Issue entity",
      "description": null,
      "expects": "vocab:Issue",
      "returns": "vocab:Issue",
      "statusCodes": [
        {
          "code": 201,
          "description": "If the Issue entity was created successfully."
        }
      ]
    },
    ...
  ]
}

along with the definition of vocab:Issue, this gives a hypermedia client all
the necessary information to dynamically render a form that can be used to
create a new issue.

Did this clarify things a bit?


Cheers,
Markus


[1] https://github.com/HydraCG/Specifications/issues/15
[2] http://www.markus-lanthaler.com/hydra/api-demo/vocab


--
Markus Lanthaler
@markuslanthaler

Received on Thursday, 21 November 2013 17:44:28 UTC