RE: First release of hydra-java for spring-hateoas in Maven central

Am 1. Oktober 2014 17:48:30 schrieb "Markus Lanthaler" 
<markus.lanthaler@gmx.net>:


> At the moment I guess I have just two questions:
>
> 1) What was the reasoning to make schema.org the default vocabulary? Do you
> think most people will just use that or do you think it would be too much to
> require developers to specify that explicitly for each package/class?

Convention over configuration. Even if I do not annotate my classes at all, 
I wanted at least some potentially meaningful output. Schema.org is also 
used by the json-ld spec and it seems a quite suitable starting point for 
many rest apis, with its focus on things of interest for search engines and 
its extension points for external vocabs. If it's interesting for Google, 
Bing, Yahoo and Yandex, chances are that there are also rest apis for it :)

The drawback: if you do not use attribute names from schema.org, they are 
meaningless for LD in spite of the @context. Ideally, the tooling should 
tell me if I have attributes that are not defined by any given vocabulary, 
and I should not need IDE plugins for that. I have some ideas there, but 
that is still "Zukunftsmusik".

>
> 2) The README contains the following example:
>
>     enum BusinessFunction {
>         @Expose("gr:LeaseOut")
>         RENT,
>         @Expose("gr:Sell")
>         FOR_SALE,
>         @Expose("gr:Buy")
>         BUY
>     }
>
>     @Term(define = "gr", as = "http://purl.org/goodrelations/v1#")
>     class Offer {
>         public BusinessFunction businessFunction;
>         ...
>     }
>
> This makes me wonder what the scope of term definitions is and how you
> handle possible "conflicts". I would assume that in this example the term
> "gr" is scoped to the Offer class and not available (yet) within the
> BusinessFunction enum... but apparently that's not the case. Could you
> please elaborate a bit on that?

Right now, nested objects will have no @context of their own unless (1) 
they define a different @vocab than the surrounding object or (2) they 
expose terms of their own. That allows to have terms within a nested 
context which redefine terms of the outer context. I do not collect exposed 
terms of nested objects into the top level context yet because I saw 
potential for conflicts. That could certainly be improved, e.g. by 
collecting terms into the root if no conflicts are detected and by pushing 
conflicting terms into sub-contexts. Otoh that seemed a mere optimization 
right now.

>
>
> > Operations are next on the roadmap.
>
> Cool!

It seems, schema.org is a bit ahead at the moment. I find 
PropertyValueSpecification very expressive, it tells the client exactly 
what it should send, in place, very much like an HTML form, see [1]. No 
sense in duplicating all that in Hydra. I'm still sorting out the overlap, 
trying to find a way to generate state-changing affordances from Java 
resource handler methods, with a minimum of special annotations in Java.
There is one thing schema.org doesn't solve, I'll bring it up in [2], as 
soon as I have a discussion-worthy proposal ready :)

> Do you also plan to implement a very simple API to illustrate how this
> all works in practice? Perhaps a port of the simple Event API [1] I
> implemented a while ago would be interesting as we could compare our
> approaches directly.

yes, and I want to put it in the cloud, too. Actually, the tests already 
contain a sample EventController which could be part of a war file.

Best regards,
Dietrich

>
>
[1] http://schema.org/docs/actions.html
[2] https://github.com/HydraCG/Specifications/issues/70

Received on Wednesday, 1 October 2014 23:19:20 UTC