This article is currently being written – 13 May 2020
An offerbot is comprised of a number of components – a database, social network, concept space and more.
[Note: There is still some ‘magic’ in my concept of offers which is of concern to me – this will need to be solved as we build offerbots]
Offers contain bundles supply (what you’re offering) and/or demand (what you want in return) represented as nested linked data.
A trade is the exchange of those two bundles – your supply in exchange for their demand.
A gift is the giving away of your bundle of supply, whether that supply is phyiscal or digital.
Externalities can also be represented (e.g. the private data requested).
Lite schema, based on demand for information –
Store offers (mine and cache others’ offers).
Store sets of offers (a set of preprocessed offers for further processing by offerbots) – mine, others’
Each offerbot can define its own concepts which can be adopted by other offerbots to describe offers (i.e. the concepts within those offers). A concept is a simple key-value pair which is represented to the public via a URL:
|bicycle||a human-powered vehicle with two wheels||https://mydomain.com/ob/c/bicycle|
|widget||a useful doodad for your whatsit||https://mydomain.com/ob/c/widget|
|supertrade||a trade in which goods are exchanged and both parties shout ‘super!’||https://mydomain.com/ob/c/supertrade|
The resource returned by the URL will be signed JSON-LD to allow caching of concepts (noting that the signature cannot be verified if the offerbot’s public key is unavailable and not cached by the .
Offerbots will need to make their owners aware when unusual.
[Products and other goods are also expressed as concepts with their own attributes and URIs (e.g. this car’s engine configuration is a V8, it has 8 cylinders, it’s available in red and green, etc.)]
Maps are representations of offers for humans. Your offerbot will store maps which have been prepared by:
- your offerbot (for you and/or for other people), and
- other people’s offerbots (for them and/or for you).
It may be that these maps are stored as rendered documents. It is more efficient (and likely), however, that they’ll be stored as data, ready to be rendered into an HTML document, email, app notification or other view (by a renderer available to your offerbot).
Each offerbot will store a representation of its owner’s social network – their relationship to other people, organizations and objects. This is done by relating the URI of offerbots to each other:
This may extend to claims of ownership of skills (of the offerbot’s owner) and the objects that they own.
To enable the encryption of offers and the signing (and subsequent authentication) of unencrypted offers, each offerbot will store its own private key and cache the public keys of other offerbots.