Re: hydra-0.2.0-alpha1 release in Maven Central

Hi Markus,

side-note: are you going to attend the W3 Rest meetup in Florence, which 
Ruben mentioned a while ago? As I read it, a full day track is expected 
- maybe several of us could demonstrate their current work there? I 
would certainly like to go there, learn about linked data fragments and 
show what I have so far. Besides, I love the city :)

Comments inline

Am 04.01.2015 um 22:11 schrieb Markus Lanthaler:
> On 4 Jan 2015 at 21:46, Dietrich Schulten wrote:
>> Hi,
>>
>> The latest version of hydra-0.2.0-alpha1 [1] is officially released in
>> Maven Central.
> Nice! Did you encounter any specific issues/shortcomings while implementing this version?

Sure, several issues caused me quite some headache

- nested json objects: currently I had to use schema:rangeIncludes as 
proposed in Issue-26 [2] since they are not possible in hydra yet. The 
resource shape WG had no useful results at this time either; I made a 
comment in #37 which explains why I am using rangeIncludes as shown in 
#26 right now. This issue is also the reason why I rather sticked to an 
alpha release.

- value constraints: I used http://schema.org/PropertyValueSpecification 
to express them, by just stating that the type of a supportedProperty is 
also schema:PropertyValueSpecification. They are modeled similar to html 
forms which I consider a very successful way to describe expectations 
for POST requests. I did not use oslc:Property from the Resource Shape 
submission because I got the impression that the Resource Shape WG is 
not committed in any way to the oslc submission, for the WG oslc is just 
an example how constraints are expressed in one current vocab. The 
biggest shortcoming of schema:PropertyValueSpecification is the lack of 
an equivalent to html select option, those are part of the Action object 
in schema.org (if someproperty and someproperty-input is present, read 
the values of someproperty as options). We have no someproperty-input, 
so this doesn't work with hydra.

- allowed values: it is not possible in hydra to tell the client about a 
known set of allowed values for literals or individuals (as in 
schema:EventCancelled). Especially the latter might pose a problem. If 
we had something like hydra:allowedValues, we could not easily say in 
the context that the allowed values are meant as individuals (as with 
"@type": "@vocab" for enum values), because there might be several 
hydra:allowedValues in the same response, some containing literals, 
others containing individuals. While I exactly know internally on the 
server side which values I would expect, I cannot tell the client (quite 
frustrating, actually). OK, there is a simple solution: if you expect 
URIs or Curies, tell the client to use them, literally. But somehow I 
feel we should be more precise than that, and stay in line with 
@type:@vocab if we can.

>
>> It allows to render a Java rest service as hydra-flavored
>> application/ld+json, based on Spring-Hateoas. Clients can request plain
>> application/json, application/hal+json or application/ld+json and will
>> get what they asked for.
> Does the server also accept the various formats in requests? Or does, e.g., a JSON-only client has to send the same JSON structure as a JSON-LD client?

The server handles json, json-ld and hal requests respectively. The 
server doesn't evaluate the @context yet, the json object must have 
attributes that match the properties of the target java bean, so it 
doesn't matter if the incoming properties are exposed as json-ld or not. 
To be entirely correct, it would be nice if the server were able to map 
an incoming json with totally different attribute names to exposed 
properties of a java object solely based on the @context. OTOH this 
seemed overkill right now. If we had hydra:allowedValues for enum 
values, things would change quite a bit of course - right now clients 
must send correct enum values, not individuals.

>
>
>> Support for operations is there, together with uri templates.
>> Several issues with 0.1.0 are also resolved, thanks to the community for
>> the feedback.
>>
>> I have still marked it as alpha mainly because of ISSUE-26[1], i.e it
>> uses schema:rangeIncludes to express nested properties in expected
>> request bodies which is likely to change in the long run.
> What else is planned for the next version?

What I would very much like to do:
Implement the solution for #26 and hydra:allowedValues, replace the 
properties from schema:PropertyValueSpecification by something in the 
domain of SupportedProperty

:)

Otherwise, see the issues list:
- xhtml representation
- support for json-ld profiles, expanded, flattened etc.
- paged resources
- warnings about undefined properties

That is what I would find useful right now. Are there other important 
points you would like to see addressed?

Best regards,
Dietrich

Received on Sunday, 4 January 2015 23:01:15 UTC