Re: Non-trivial trading flows with schema.org

Hi,

Am 22.02.2015 um 00:55 schrieb Andrew Hacking:
> Dietrich,
> 
> I think this is really useful scenario for working through the nuances
> of exactly what is needed for a generic client to actually be able to do
> something semi intelligent.
> 
> One thing I found troubling was that to place an order why would you
> transpose the product name to the order and not just reference the
> offered product?

Mainly because Webber's restful coffee shop does it. Since there is
schema:productId, it would be easy to pass a product number and @id,
too. Or to pass only a product number, or only the @id. The beauty is,
the server is completely free to make the client pass whatever pleases
the server :). Or to change it in the next server version.

> 
> Other inevitabilities I see is that to place an order you will
> additionally need the the quantity, 

exactly, I asked that on public-vocabs, too. For now I am happy to post
twice for two Latte Macchiato, but indeed there seems to be no
schema:quantity property.


> perhaps you also need to vary the
> order (add sugar, lactose free milk), and maybe also order a coffee for
> your colleague and actually pay with some payment method accepted by the
> shop, and are you having your coffee take away or on the premises?

I am having the coffee downloaded to my desk :o)

But seriously, these are the exact steps I want to tackle next. In
schema.org there is addOn, paymentMethod, deliveryMethod etc., so I hope
we can express most of that. There are even schema:Product subtypes in
productontology.org which one might use as @type in addition to
schema:Product:

http://www.productontology.org/doc/Latte_macchiato
http://www.productontology.org/doc/Sugar
http://www.productontology.org/doc/Milk

"itemOffered":{
  "@type": ["Product","pto:Latte_macchiato"],
  "@id": "http://example.com/products/latte"
  "name": "Latte Macchiato"
}

I already checked, there is no
http://www.productontology.org/doc/Lactose_free_milk
because there is no such article in wikipedia. We would have to add such
an article. It should be an interesting experience to do it and see how
quickly a missing product type becomes available in productontology.org.

> 
> How would you express that there transitions which can only be taken
> which may have more complex requirements or rules?  Imagine ordering a
> sandwich with many possibilities of ingredients that are tied to the
> shop. The shop may sell ham, cheese, avocado, lettuce and mayo on
> various bread types but within the context of various sandwich like
> constructions, meaning there are rules about what makes sense, eg you
> may be able to order extra cheese but double bread isn't sensible, and
> it may not be possible to have chicken, ham, tuna and meatballs on a
> single sandwich because that's just too difficult for the shop to
> process and fit on a single sandwich. 
> The client can't submit the order
> without composing a sensible list of ingredients first which may have
> many parts and is dependent on the selection of many ingredient
> resources with rules. Whilst all those ingredient resources could
> transition to an order would you express that possibility and all the
> rules on every single ingredient? Would you prescribe building a
> sandwich in steps (ie a workflow starting with the bread followed by
> ingredients like an assembly line? )

The question "what is possible next" is the motor of hateoas, so right
now I am optimistic that it can be designed.

> 
> Oh, and I also want it to support group ordering eg for 10 people in my
> office. (See what that does to a workflow approach)

For the group ordering scenario one could imagine that the group order
is a kind of collaborative effort. An initiator could share /order/1234
and people can make additions to it.

In my picture the generic client sits between the UI and the server.
There can be a UI that freely arranges the data in the frontend to make
things convenient for humans, and I imagine it as a single page
application or a mobile app, so the request-response cycles take place
in the background, not as page reloads.

E.g. the UI could list the offered items and add-ons with checkmarks or
with add-remove double lists or as draggable items. It would then feed
the generic client with the necessary information.

What I have in mind is that the UI builds a request for the generic
client like "from Kaffeehaus Hagen, order a latte macchiato with shot
and pay with Mastercard, come back for payment authorization" and the
client handles it accordingly. The point of the generic client would be
that I could say the same thing for "Cafè Schümli", without writing a
new client. Imagine what it means for businesses if they can offer
products and services by putting up an API which can be accessed
immediately by existing clients.

I am not aware that such a generic client exists. I started with the
chicken, hoping that eventually it will lay an egg :)

I do not think we can decide if such a generic client makes sense or is
feasible in theory. I also don't like to discuss that in theory.
Those who think it is feasible and makes sense must prove it by building it.

> 
> How far can you really get with a generic client  being practical for
> end users? I think that is an important question because the further you
> go with this the more you bake UI into the state exchange and the more
> you assume the resource knows the application state (which is not true
> in modern web applications).

The service must be careful not to be tied to a specific UI flow. But I
do not think it is, just because it has its own flow.

A single-page application UI has its own application state. The UI uses
the hateoas application states to achieve its tasks. That is how I sort
out the relationship currently.

Best regards,
Dietirch

Received on Sunday, 22 February 2015 10:43:05 UTC