Re: hydra-0.2.0-alpha1 release in Maven Central

Hi Markus,

Am 05.01.2015 um 20:13 schrieb Markus Lanthaler:
> 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.

I'll try to come up with something. I would be more comfortable, if 
someone with extensive rdf experience would be there, too, to explain 
the rdf foundations of hydra. I know my ReST stuff, but RDF is a vast 
field.

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

Yup. I thought so, therefore I thought I might as well go forward with 
nesting by means of rangeIncludes :)

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

Very much so. I spent a whole day reading the Resource Shape WG meeting 
minutes, pulling out a considerable portion of my greying hair. 
Especially when I realized that I had spent another half day in vain to 
apply the oslc submission to hydra although it is just one of many 
possibilities the WG is considering. One needs very special gifts to 
handle WG discussions ;)


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

I am afraid so, yes. But now there is hydra-java #12 :)

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

Thanks for the encouragement. I'll sum up alternatives and try to come 
up with a workable proposal, observing the Shapes WG progress at the 
same time.

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

Well, OK, I guess it is inevitable anyway in the light of the now 
upcoming proposal to describe valid requests: 
https://github.com/dschulten/hydra-java/issues/12

:P

Best regards,
Dietrich

Received on Monday, 5 January 2015 20:45:59 UTC