Add weight to orderline

[RachL]

An "Orderline" has a relation "hasQuantity" linked to a "QuantitativeValue" where a unit can be attached.
This unit can be a weight (products sold by kg for example),

However what's missing is the weight sold when the product is sold in items of different weight (case of meat & cheese products for example).

This field can also be useful for handling delivery/logistic.

Previous discussions

datafoodconsortium/prototype#116 (comment)

[RaggedStaff]

Thanks for raising this @RachL

Just to clarify, you're asking for an additional quantativeValue to be linked to orderLine with something like hasWeight and a unitType fixed as kg or grams or something ?

Secondary query for @Alcoz - is there a way we can constraint the qV like this (to only allow certain unitTypes (and how would we identify those types: perhaps a broader SKOS category 🤔 ) ? Or would it be easier to have a subtype of qV (like temp) ?

[RaggedStaff]

@RachL - Quick question : when do you need this for ?

Could we include in v2.0 (no date yet for that, prob later this year) ?

[RachL]

@RaggedStaff no fixed deadline on my side, but I suspect OFN will want to know this before Maikel finishes the Orders API? It's quite a key field on the orders side. Maybe we can review once OFn has listed all the missing fields? This might not be the only one.

[RaggedStaff]

@RachL - talking this through, we believe the Product weight should be on the SuppliedProduct - either as a gross weight (e.g. a box = 450g) or a reference weight (e.g. price per kilo). If we have that & the quantity (from the OrderLine) we can calculate the weight.

Does that make sense ?

[RachL]

@RaggedStaff I don't think we can base this weight only on something we calculate.

I agree that this proposal will work for a box of X kg or a product sold by weight, but with a fixed weight / a weight known in advance.

However there are products, like cheese and meat for which we don't know the final weight during the sale session.
The weight will change per lineitem / the value is adjusted after the order has been completed by the customer, when the order are prepared.

E.g. customer A receives a slice of 230g of cheese and the customer V receives a slice of 280 g of cheese - even though both have made an order of 250g of cheese.

Each shop has is own rule in terms of payments: some give the difference in vouchers, some others propose to pay for the exact weight etc

I think we need to cover all these cases. Having non-standardised product is a big difference of short vs long supply chain.

[RaggedStaff]

@RachL I agree, we need to cover non-standard processes like these.

I'd like to explore the cheese example a little more:

In the event the customers pay the same & the producer applies a discount/refund, that could be applied to Order:Discount

When the customer is charged based on the actual weight of the cheese they receive, then wouldn't the OrderLine need to be amended to reflect the actual charge made to the customer ?

There is a further thing to mention - in last weeks Ontology call we discussed the fact that actual shipments should be PhysicalProducts (not SuppliedProducts as are currently linked to OrderLine, via Offer). I wonder if that might help to hold this complexity: the PhysicalProduct could have a precise weight in grams, rather than an average weight. WDYT? 🤔

[lecoqlibre]

The use cases described by @RachL are all valid use cases and the ontology should be currently able to capture them (every needed concept and predicate should be available).

The ontology gives means to these use cases to be expressed. But it can't state how they have to be implemented. This has to be described and defined in the standard or a certain part of the standard (what Solid calls client-to-client standards).

[RaggedStaff]

OrderLine already hasQuantity, which can be a weight (an OrderLine can have mulitple Quantities associated with it).

Proposal that an additional quantity (of the exact weight) is added to the OrderLine to detail the exact weight of the sold product.

@RachL - does that work ?

[RachL]

@RaggedStaff yes. This solves the use case of a product sold by weight but for which each item sold will have a different weight.

Just to be sure: when we have a product sold by item and we want to add the weight for logistics reasons, do we already have a dedicated field for that?

[RaggedStaff]

@RachL - we are proposing to add hasWeight to PhysicalProduct - this can cover both use cases you mention: with the new relationship fulfills/isFulfilledBy between OrderLine & PhysicalProduct.

Does that work ?