RE: representing hypermedia controls in RDF

On Friday, November 22, 2013 11:27 AM, Ruben Verborgh wrote:
> > 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?

A link is an affordance, a property defines a relationship using
identifiers.


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

Right, but nothing indicates to a client that he might wanna try to
dereference :Band to find more information about that thing.


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

Exactly. An affordance.

 
> 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 same that happens all the time on the Web. You get a 404 or another
error but that doesn't change anything on the fact that it represent an
affordance. If you see a door handle you usually expect that you can use it
to open the door it is attached to. Sometimes that won't work. I doubt that
someone would come to the conclusion that if some door handles don't work,
the whole idea of door handles is broken. Right? :-)


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

You forgot the link but nevertheless, are you saying that

  hydra:Link rdfs:range hydra:Resource .

  :myprop rdf:type hydra:Link .
  </something> :myprop </something-else> .

entails

  </something-else> rdf:type hydra:Resource .

? I don't think so, but I would love to be proven wrong. That would just
work if hydra:Link would be a property itself and you create sub-properties
thereof.


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

Something like this would definitely make sense in my opinion. I've created
ISSUE-16 [1] to keep track of this.


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

But at the same time you require everyone to type their strings accordingly.
I already hear you saying "no, you can set rdfs:range and it will be done
automatically". Yeah, that would work in the short term, but you'll never be
able to change that again. So as soon as you start to support a second
format, you need to start typing your strings. And that's exactly same
situation as we have now. We interpret plain strings as RFC6570 templates.
If there's really something better coming up in the future, it's early
enough to start typing those strings. It's just as extensible. 

But that's of course just my personal opinion. I would love to hear other
opinions as well. I've created ISSUE-17 [2] to keep track of these
discussions.


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

I doubt that very much. The target group of Hydra are average web developers
not semantic web experts. Those will understand themselves that they can use
this stuff with, e.g., Turtle as well. I don't want to confuse Web
developers with multiple serialization formats or "triples". Almost all
current Web APIs use JSON. Developers think in terms of objects and
properties. Thus, JSON-LD is the most natural serialization format. I hope
the issue tracker demo on my site illustrates this.


> Especially in the case of the vocabulary, it does not make much sense
> to have JSON-LD.

I've added a link to a Turtle serialization of the vocabulary as requested
by Kingsley, that should hopefully address most concerns.


> Not many JavaScript applications will read vocabs; those that do have
> an RDF library anyway.

This almost sounds as you could work with Turtle without a RDF library. You
know that that's not true at all. On the other hand, it's is very easily
possible to achieve a lot without special libraries by using JSON. The issue
tracker demo, e.g., doesn't use any RDF library (even though it would
probably be much simpler to use a local triple store or something similar).


> For instance, my understanding is quite slowed down by the syntax.

That's the first time I hear something like this. The JSON-LD really slows
you down? How? What exactly would be clearer if Turtle would be used
instead?


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

Sure, we could do that and add Turtle examples in the future. For the time
being I would prefer to keep it simple and stick to JSON-LD. I'm sure you
understand that.


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

Cool!


> Would you also use something like this for GET forms, or would that be
> reserved for URI templates?

I would use IRI templates for GET requests.


Thanks for your thoughts and suggestions,
Markus


[1] https://github.com/HydraCG/Specifications/issues/16
[2] https://github.com/HydraCG/Specifications/issues/17


--
Markus Lanthaler
@markuslanthaler

Received on Friday, 22 November 2013 15:05:26 UTC