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

On 6 Okt 2014 at 18:32, Dietrich Schulten wrote:
> Am 6. Oktober 2014 13:08:48 schrieb "Markus Lanthaler":
>> 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].

Well, yeah. They would need to learn about that but it's pretty easy:
include an example in the README that people can copy and paste :-) IMO
people really need to understand that there is a mapping to make use of this
library... but obviously you are the one to decide that.


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

Yeah, limit the scope of those annotations. In the example above that would
mean that the prefix "gr" would have to be an annotation of the enum
BusinessFunction instead of the class Offer. If you want to use those things
in multiple places, add those annotations to the package.


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

Because it kind of defines new properties etc. on the fly whose semantics
depend on its IRI structure:
  http://schema.org/name -> http://schema.org/name-input


> Do you plan similar input constraints in hydra? Or is there a

Yes, in some form or another. Currently we just have readable/writeable but
nothing prevents us from adding more.


> better way in json-ld? With my Javascript background, I find the html
style
> very appealing, clients can blindly apply them in a browser.

Applying things "blindly" is always a *huge* security risk.


--
Markus Lanthaler
@markuslanthaler

Received on Monday, 13 October 2014 14:13:57 UTC