Re: representing hypermedia controls in RDF

> Right, nothing has hydra:Link as range because it's a specialization of rdf:Property.

What would be the difference between a link and a property?

All rdf:Properties are "links" (in the English sense).
Even the most basic relation of all is a link:
  :Daft_Punk rdf:type :Band.
You find them on Wikipedia all the time.

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

So Link is a dereferenceable rdf:Property, that's it?
Makes sense.

Devil's advocate here: what if the link breaks, i.e., the object part goes permanently down (e.g., server closes)?
Then it's not dereferenceable anymore.
The problem seems to be that dereferenceability is a temporal thing.


> The spec doesn't include any entailments yet

And never should, RDFS and OWL properties are enough.
With the rdfs:range of hydra:Link being hydra:Resource, you have everything you need.
Entailments for RDFS and OWL are already defined (e.g. [1]).

> Well, same thing in principle
> 
>  :membersHaveTemplate a hydra:TemplatedLink .
> 
> Of course Hydra can't know what :membersHaveTemplate really *means*

Well, that's exactly what I propose.
This precise link is going to be so common that I think we want it in Hydra itself.
Perhaps "memberTemplate" is a better name.
(Note: I'm unsure on how to use the hydra:members predicate, I might be doing it wrong.)

Example of what I'd like:

</users> hydra:members </users/alfred>.
</users> hydra:members </users/bernard>.
</users> hydra:members </users/corey>.
</users> hydra:membersTemplate [
                        a hydra:IriTemplate;
                        hydra:template "/users/{userid}"
].

The semantics of the hydra:membersTemplate property would be:
"members can be dereferenced by using the following template".

(Not: "members need to have this template".)

Would such a property fit in the Hydra core vocabulary?

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

It's not as much about complicating as about being exact.
The thing is not a string, it's an RFC6570 template.
Please seize this opportunity :-)

Note that this even enables future extensibility automatically.
If RFC25000 suddenly comes up with another template,
it can be supported out of the box:

<x> hydra:template "old-template"^^hydra:rfc6570Template.
<x> hydra:template "new-template"^^rfc25000:template.

So the same resources can have multiple templates in different standards.
That's extensibility.

> 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

Ah, missed the @id because I'm so used to reading Turtle.
I see where this is going now!

Meta-remark: did you consider giving the examples in Turtle?
You would reach a broader audience that way.
Especially in the case of the vocabulary, it does not make much sense to have JSON-LD.
Not many JavaScript applications will read vocabs; those that do have an RDF library anyway.

For instance, my understanding is quite slowed down by the syntax.
You could add some JavaScript to the page that can toggle between Turtle and JSON-LD,
if you want to maintain JSON-LD as well. (Just a thought.)

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

> Did this clarify things a bit?

Absolutely. This last part might just be what I need to represent form operations.
Would you also use something like this for GET forms, or would that be reserved for URI templates?

Cheers,

Ruben

Received on Friday, 22 November 2013 10:27:03 UTC