Re: How to GET a cup of coffee - Restbucks with Hydra

Hi Gregg,

thank you for looking into this.



On March 8, 2015 9:10:06 PM Gregg Kellogg <gregg@greggkellogg.net> wrote:

> > On Mar 8, 2015, at 11:08 AM, Dietrich Schulten <ds@escalon.de> wrote:
> >

>
> This doesn't really say what you want. IIRC, there is a hydra:object 
> property that can be put in the manages block to imply that the collection 
> members are subjects of that relationship rather than objects.

...

> However, this doesn't seem right. The result of an operation would be 
> something like the following:
>
> {
>   "@type": "Order",
>   "productId": "latte-1"
> }

No, the response to the POST would be an Order with an orderedItem.

>
> In which case, the this would be related using the orderedItem property to 
> the entity associated with the collection (a store):
>
> {
>   "@type": "Order",
>   "productId": "latte-1",
>   "orderedItem": "http://example.com/store"
> }
>

I do not understand why the store becomes the object of orderedItem here, 
there was no triple which stated that. Is there some general assumption at 
work which relates the previous response (which was a Store) to the 
response of the POST (the Order)?

> I would think this would, in fact be a forward relationship from customer 
> to their order:
>
> {
>   "@type": "Person",
>   "orderedItem": {
>     "@type": "Order",
>     "productId": "latte-1"
>   }
> }

The restbucks service (in Webbers blogpost) does not associate the order to 
the customer. Which also makes sense, if you think about it - there are 
many cases where the customer can be anonymous, also on the web.

>
> So, just using the orderedItem as the hydra:property relationship is 
> probably what you intend. Interestingly, due to the way @reverse works, 
> this is, in fact, what you are saying, because @reverse doesn't have the 
> intended effect when using as a value rather than a property.

Wow, surprise! Is that a bug in the playground, a gap in the json-ld spec 
or is it really intended that a reverse property becomes the unreverted URI 
when used as an attribute value with @type:@vocab?

Actually that helps, we could then safely @index the collection items by 
the property URIs.

> So, using hydra:subject instead of hydra:object in the manages block is 
> probably the right thing.
> ...
> "hydra:subject": "http://example.com/customer"


In Webber's restbucks the orders are at an /orders resource below the 
store. So what I want is the store as a subject, if I *have* to name the 
subject. And I can drop the @reverse on orderedItem in the Wiki.

I'll adjust the Wiki accordingly.

More of a background question:

The mechanics of the manages block seems to be that the collection members 
are either subject or object of the collection triples. Which of both the 
members are, depends on the presence of subject or object. If there is a 
subject, the members are the object and vice versa.

The question is, what exactly do we say if the manages block only contains 
a property, but no object or subject? I would assume we say that the 
collection manages the property, but we leave it undefined if the items are 
subject or object. Maybe it would be preferable if the managed block would 
not make the members a subject or object by omission, but by asserting 
exactly what they are.

Best regards,
Dietrich

Received on Wednesday, 11 March 2015 09:01:16 UTC