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

Am 6. Oktober 2014 13:08:48 schrieb "Markus Lanthaler" 
<markus.lanthaler@gmx.net>:

> On 2 Okt 2014 at 01:18, Dietrich Schulten wrote:
> > Am 1. Oktober 2014 17:48:30 schrieb "Markus Lanthaler":

> It is very little work to require to add an explicit
> mapping to schema.org at the package level but "forces" developers to think
> about this mapping.

OTOH people will first have to learn how to annotate packages and ask 
questions about that. I'll look into ways to warn developers about 
undefined attributes, I promise [issue #5].

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

>
> So, by reading this exaplanation you see the enum BusinessFunction above as
> a "nested object" of the Offer class and not as something standing on its
> own? What if the same enum is used within two different classes which map
> "gr" to different URLs? Would that mean that the same enum value would be
> mapped to two different URLs depending on the class it is used in?

Good point. If gr: is not defined or defined differently in another class, 
nonsense would be the result. We need some validity checks for sure to 
detect that kind of problems.

Other than having a smarter serialization which avoids nested @context 
definitions as much as possible by pulling terms into the top level 
@context when feasible, and some kind of validation - do you see other 
approaches to solve this?

>
>
> >>> 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
>
> Yep, it defines more constraints ATM. I'm not that much of a fan of the
> annotation model it uses (<property>-input / <property>-output) though.

Why is that? Do you plan similar input constraints in hydra? Or is there a 
better way in json-ld? With my Javascript background, I find the html style 
very appealing, clients can blindly apply them in a browser.

Best regards,
Dietrich

Received on Monday, 6 October 2014 16:33:09 UTC