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

On 2 Okt 2014 at 01:18, Dietrich Schulten wrote:
> Am 1. Oktober 2014 17:48:30 schrieb "Markus Lanthaler": 
>> 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
:)

Sure


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

That's what triggered my comment. It makes things a bit too convenient IMO.
I'm afraid that people won't really understand what's going on and just keep
using it this way instead of thinking about the mapping to Schema.org (or
any other vocabulary). 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.


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

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?


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


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

Great.


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

Awesome. This will be very valuable and helpful for future design decisions.


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


--
Markus Lanthaler
@markuslanthaler

Received on Monday, 6 October 2014 11:08:25 UTC