RE: hydra-0.2.0-alpha1 release in Maven Central

Hi Dietrich,

On 5 Jan 2015 at 00:00, Dietrich Schulten wrote:
> 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 :)

You probably mean WS-REST [1]. That's not a meetup but an academic workshop. I don't think I'll be there but I'm on the program committee which means that I'll review a few of the submitted papers.


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

OK. Unfortunately, I can't add anything to this that hasn't already been said at this point..


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

These are points are closely related to the first point you raise I guess: we need a better way to describe what's expected in a valid request.


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

OK. So sending the JSON-LD in expanded form would currently break everything, right?


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

If you have some time for this, you could start to sketch out a design (or multiple) so that we have something concrete to discuss. Feel free to either add a page to our Wiki or raise an issue.


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

Maybe accepting arbitrary JSON-LD forms instead of requiring a specific structure? :-P


[1] http://ws-rest.org/2015/


--
Markus Lanthaler
@markuslanthaler

Received on Monday, 5 January 2015 19:13:49 UTC