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

> On Mar 8, 2015, at 11:08 AM, Dietrich Schulten <ds@escalon.de> wrote:
> 
> Hi,
> 
> I have added a Wiki page which collects previous emails about trading
> flows with schema.org and adds one more use-case: Continue Shopping
> 
> https://www.w3.org/community/hydra/wiki/Restbucks_with_Hydra
> 
> Initially, it covers the use cases:
> - Telling the client how to order based on offers made by a business
> - Allowing the client to add or remove add-ons to the initial order
> - Continue shopping
> 
> Please have a look and give feedback.

This is a great use case. However, I think that using "orders" as the value of "hydra:property" is problematic, as if you were to expand this bit, you'd get the following:

{ 
   "@context": ["http://schema.org", {
     "@vocab": "http://schema.org/",
     "hydra": "http://www.w3.org/ns/hydra/core#",
     "hydra:property": {"@type": "@vocab"},
     "orders": {"@reverse": "orderedItem"}
   }],
   "name": "Latte Macchiato",
   "hydra:collection": [
     {   
       "@type": "hydra:Collection",
       "@id": "http://example.com/orders",
       "hydra:manages": {
           "hydra:property": "orders"
       },
       "hydra:operation": {
         "hydra:method": "POST",
         "hydra:expects": {
           "hydra:supportedProperty": [
             {
               "@type": "PropertyValueSpecification",
               "hydra:property": "productID",
               "hydra:required": true,
               "defaultValue": "latte-1",
               "readOnlyValue": true
             }
           ]
         }
       }
     }
   ]
 }

(try it in the playground here: http://tinyurl.com/n6wf5x5).

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. This might look like the following (http://tinyurl.com/os5d24a):

 { 
   "@context": ["http://schema.org", "http://www.w3.org/ns/hydra/core", {
     "@vocab": "http://schema.org/",
     "hydra:object": {"@type": "@id"},     
     "hydra:property": {"@type": "@vocab"}
   }],
   "name": "Latte Macchiato",
   "hydra:collection": [
     {   
       "@type": "hydra:Collection",
       "@id": "http://example.com/orders",
       "hydra:manages": {
         "hydra:property": "orderedItem",
         "hydra:object": "http://example.com/customer"
       },
       "hydra:operation": {
         "hydra:method": "POST",
         "hydra:expects": {
           "hydra:supportedProperty": [
             {
               "@type": "PropertyValueSpecification",
               "hydra:property": "productID",
               "hydra:required": true,
               "defaultValue": "latte-1",
               "readOnlyValue": true
             }
           ]
         }
       }
     }
   ]
 }

However, this doesn't seem right. The result of an operation would be something like the following:

{
  "@type": "Order",
  "productId": "latte-1"
}

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 would think this would, in fact be a forward relationship from customer to their order:

{
  "@type": "Person",
  "orderedItem": {
    "@type": "Order",
    "productId": "latte-1"
  }
}

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. So, using hydra:subject instead of hydra:object in the manages block is probably the right thing (http://tinyurl.com/nlbutaq):

 { 
   "@context": ["http://schema.org", "http://www.w3.org/ns/hydra/core", {
     "@vocab": "http://schema.org/",
     "hydra:object": {"@type": "@id"},     
     "hydra:property": {"@type": "@vocab"}
   }],
   "name": "Latte Macchiato",
   "hydra:collection": [
     {   
       "@type": "hydra:Collection",
       "@id": "http://example.com/orders",
       "hydra:manages": {
         "hydra:property": "orderedItem",
         "hydra:subject": "http://example.com/customer"
       },
       "hydra:operation": {
         "hydra:method": "POST",
         "hydra:expects": {
           "hydra:supportedProperty": [
             {
               "@type": "PropertyValueSpecification",
               "hydra:property": "productID",
               "hydra:required": true,
               "defaultValue": "latte-1",
               "readOnlyValue": true
             }
           ]
         }
       }
     }
   ]
 }

Gregg

> The point to prove is that with Schema.org and hydra, we have the
> necessary properties to support non-trivial trading flows. Non trivial
> in the sense that we can do much more than simple "Buy this product"
> interactions.
> 
> If the wiki article has no fundamental flaws and hydra services and
> clients use the properties as proposed in the wiki article, we have
> discovered nothing less than a media-type with semantics for universal
> trading flows. I.e. if someone puts up a service and offers goods as
> outlined by the article, every hydra client could work with the service.
> Payment and delivery are open points, but I didn't run into
> unsurmountable problems so far, so I tend to hope we can design that, too.
> 
> Note to self: ask Manu Sporny about web payments in this context :)
> 
> If that succeeds, we would have created the equivalent of atom for
> newsfeeds, only for trading flows. You need only one client to handle
> many trading locations.
> 
> Best regards,
> Dietrich
>

Received on Sunday, 8 March 2015 20:09:29 UTC