- From: Dietrich Schulten <ds@escalon.de>
- Date: Wed, 11 Mar 2015 10:00:46 +0100
- To: Gregg Kellogg <gregg@greggkellogg.net>
- CC: Hydra <public-hydra@w3.org>
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