Domain Category.

[venkatramanm]

Given the number of domains mushrooming each day, having a generic BAP to cater to all domains is becoming necessary. The challenge in creating such a generic application is the number of use cases/ flows that need to be catered for in each domain.

We are proposing here an approach that exploits domain similarities to arrive at generic buyer experience that does not depend on the actual domain but instead on a meta information about the domain, (a domain category if you will) .

The basic idea is to categorise items/resources traded on the network based on these dimensions. (first cut, We can arrive at more dimensions if needed after discussing in the community)

Resource category	Used For Transport	Transportable	Usage
Goods, Service	Y/N	Y/N	SCHEDULE/CONTINOUS

Based on these dimensions we have arrived at these category of resources being traded.

domain_category_name	resource_category	used_for_transport	transportable	usage	example
BUY TRANSPORT VEHICLE	GOODS	Y	Y	CONTINUOUS	(Buy Car, Truck, Yact, ship , Plane...)
HIRE TRANSPORT VEHICLE	GOODS	Y	Y	SCHEDULE	(Uhaul, Car Rental)
HIRE TRANSPORT SERVICE	SERVICES	Y	Y	SCHEDULE	(Travel Tickets, pass , Ride hailing, Logistics...)
BUY GOODS	GOODS	N	Y	CONTINUOUS	(Commerce, Retail , B2B, purchasing a transport vehicle..)
HIRE SERVICE	SERVICES	N	Y	SCHEDULE	(House maid, Employment , Doctor, Nurse..., )
BUY IMMOVABLE GOODS	GOODS	N	N	CONTINUOUS	(Realestate)
HIRE IMMOVABLE SERVICE	SERVICES	N	N	SCHEDULE	(Contracting a services company)
RENT GOODS	GOODS	N	Y	SCHEDULE	(Renting camera for a function)
RENT IMOVABLE GOODS	GOODS	N	N	SCHEDULE	(Realestate,Renting a hall for an event.)

Recommendation

If we attach domain_category_name mentioned above with the items as an item_tag, we may be able to build experience layer based on this nature of the item being ordered. For e.g deciding to ask some questions may be derived from the domain_category of item being ordered.

1. delivery requirement,
2. Asking buyer location
3. Knowing when to ask for booking appointments....

@ravi-prakash-v @pramodkvarma thoughts?

[venkatramanm]

@sjthnrk @vbabuEM

[ekatma]

A transaction can be seen as acquiring rights to a good (physical or digital) or service for a certain/indefinite validity period.

Consider in the domain of mobility. Let's say user parks his car (first mile), hops onto a metro / train / tram / bus (mid-mile), and takes a cab (last-mile) to complete his trip.

1. Parking is acquiring parking right to a parking space (physical good if looked at parking space, digital good if looked as rights to a parking space) for a certain validity period.
2. Metro is acquiring a ticket (digital good) valid for a certain period.
3. Cab is acquiring a service (a service is being delivered, there is a service provider who provides a service around a good) for a certain time period.

Consider purchasing a car. One acquires the rights to the car as good for indefinite period.

Consider renting a car. One acquires the rights to the car as good for a certain period.

Consider shared mobility service provider. One acquires the rights to use the service for a certain period.

So we may be able to further trim it down to a necessary if not sufficient basis:

• resource_category: good, service
• validity: timeframe being certain or uncertain / indefinite

I am wondering by this definition if immovable property is then needed.

@venkatramanm @ravi-prakash-v @pramodkvarma @sjthnrk

[venkatramanm]

Good points.

These were classified fromthe standpoint of buyer app flow..

An immovable property cannot be delivered

But a movable one can be transported to the place where needed.
So the meta information of whether some thing is movable, could be useful in design of user experience. .

Thinking aloud

[ekatma]

Good point. More meaningfully, how to acquire the rights to the good/service. what to acquire is independent of the movable/immovable property.

Consider parking space, it is an immovable good. The transaction has nothing to do whether parking space is movable or immovable. Consider real estate purchase. It is an immovable good again. The transaction then is for a certain real estate, the buyer acquires rights to the good.

Consider a movable resource like a cab service. It suffices to know the status of the service - cab is approaching, trip started, trip ended. The status is also applicable for the immovable resources - parking is active, parking right has expired.

So then it drills down to:

1. what resource is it for which rights are being acquired
2. how to acquire - order, payments
3. status of acquisition

[sjthnrk]

The operating attribute in beckn is “Item” against which the intent can be expressed. Item could be a goods or service. The item can carry resource as a sub feature but that’s incidental. Item can be based on resource or even otherwise. This agnosticity is deliberate and it’s upto BPP to define the association of resource to Item. The only thing that matters is what is defined as Item on which I can execute a contract to fulfill the intent. In your particular scenario, items calls out the nature of use of resource. So for me item of “car rental” is different from “car sale”, is different from “ride” and “car parking”. And even “rent a car seat in a ride”(car pooling). The fact that many of them have common resource attached to them incidental. Catalog items exist independent to each other. It is possible that independent disconnected items can have same resource attribute. In case of car parking, it could have two resources - car and parking but the quality of they being movable or immovable doesn’t not influence the Item definition is defined by nature of use more than the resource in play. I can apply that for even consumables like a shampoo. “Buy shampoo” or “buy shampoo monthly subscription “. It is always the nature of use that takes precedence to the actual resource in play.