Re: remove hydra:Resource and hydra:Class

Hi Gregg, Markus,

> >  [..]
> > I'm still on the fence about removing hydra:Resource and hydra:Class. For me
> > they are hypermedia controls as well.. but it might be that we can design
> > them better. I have to think more about it... and I guess we have more
> > important stuff to figure out at the moment -- no, I didn't forget about
> > paged collections :-)
>
> I'm +1 on removing hydra:Resource & hydra:Class. For my use, the only things I
> trust are dereferencable are in my own domain, and are marked up by making the
> properties subclass hydra:Link; this is adequate for me.

I can dig the point about them being used as hypermedia controls. I find browser
extensions such as Skype click-to-call really annoying when the assume anything
that looks like a phone number can be called, here assuming that all HTTP URIs
could/should be dereferenced seems similar. Would be nice to be able to make
this explicit that it is intended to dereference something.

Just thinking out loud, but I struggle to think of practical cases for use of
hydra:Resource that could not be covered by hydra:Link. In that if I have a
representation of a resource would that ever contain statements about another
resource without there being a link to that resource somewhere in the data at
hand? Perhaps inbound links might be such a case, but then I would assume it
would be preferred to indicate the type of that resource so the client can make
some smart decision whether to fetch it, in which case the relevant class would
be stated to be a hydra:Class.

It seems be stating the obvious to say any resource that I have already
dereferenced is a hydra:Resource in it's representation because that is obvious.

John

>
> Gregg
>
> > --
> > Markus Lanthaler
> > @markuslanthaler
> >
> >
>
>