From 05d8e9adaf50755d38e57800982e00ebb5f42b54 Mon Sep 17 00:00:00 2001 From: lash Date: Sat, 21 May 2022 12:06:26 +0000 Subject: [PATCH] Add datatype drafts --- drafts/entity.md | 98 ++++++++++++++++++++++++++++++++++++++++++++++ drafts/location.md | 52 ++++++++++++++++++++++++ readlist.bibtex | 6 +++ 3 files changed, 156 insertions(+) create mode 100644 drafts/entity.md create mode 100644 drafts/location.md diff --git a/drafts/entity.md b/drafts/entity.md new file mode 100644 index 0000000..79d04d4 --- /dev/null +++ b/drafts/entity.md @@ -0,0 +1,98 @@ +# A marketplace protocol optimized for localized trade of basic needs + +Same structure for asks (queries) and bids (stores, offers) + +## Usecases + +* transport (rides, deliveries) +* accommodations +* store with permanent location +* store with single dynamic location +* store with routes (multiple schedules and locations) + + +## Core entity + +* identity public key +* version (see changes below) +* location + +### Location + +* polygon (city boundary) or point/sphere (e.g. entrance, pick-up spot) +* origin only (e.g. store) or origin/target pair (e.g. rideshare) +* categories (entrance, delivery radius, drop-off point...) + + +## Optional core information + +### Times + +* schedules (opening hours) and one-offs (weekly market) +* ranges and point/sphere ("pick up around") +* negations ("but not between", "but not on") +* categories (store opening hours, transport time window, accomm lease time, reservation deadline ...) + + +### Product + +* uuid (in the domain of the entity identity key) +* rdf schemas +* should be loosely defined so that entry can be "groceries" and price ranges +* extrapolate price to citing price on reference products against a price oracle, (but still instantiate) +* each article can be stated in both spot and range in multiple currencies + + +### Contact: + +* URN (email, msisdn, im...) + + +## Auxiliary information + +Client itself chooses and assembles providers / indexers. + +* Entity description +* Linked resources (website, social media...) +* Municipality data (e.g. street address) +* Ratings +* Trust graphs +* Payment providers + + +## Datatypes + +### Point/sphere + +* optional progressive distance weighting formula, e.g. prefer items closer to the point (linear, curves...) or equally anywhere within sphere + + + +## Changes + +* Version number increments for every change, no matter frequency + + +### Mutability + +* Delta can contain only changes (add, delete) + + +### Overides + +* time overrides, like "open now" +* availability overrides, like "sold out" +* price overrides, like "everything 50% off" + + +### Pubsub + +* rapidly changing data +* entity that is moving around (taxi) +* prices that rapidly change (auctions) + + +## vocabulary: + +* how does a vocabulary of "bare necessities" look like? (wood, maize, chicken, coal, single bed, car seat) +* should not require map through language hub (english) diff --git a/drafts/location.md b/drafts/location.md new file mode 100644 index 0000000..7f3f529 --- /dev/null +++ b/drafts/location.md @@ -0,0 +1,52 @@ +# Location filter + + +Using DHT, geopositional ranges could be used as a prefix to scope indexes and route queries. + + +Earth circumference is around 40000 km. + +Divided into 256 units, each unit would span around 150 km, which would constitute a feasible full-day roundtrip with motorized transport. + +Further divided into 16 units, each unit would span about 10km, which would constitute a feasible full-day roundtrip on foot (which is the reality of mobility for most people in the world). + +Further divided into 64 units, each unit would span around 150 metres, which is a couple of minutes' walk, or the equivalent of "what exists where I am right now," i.e. the smallest resolution needed in practical terms. + +In practice, the units would be defined by degrees, conventionally starting at 0N 0E. + + +## Location filter base representation + +The above allows us to express the location scope in a series of three bit fields, + +- layer 1: bit 0-255: units of ~150 km +- layer 2: bit 256-269: units of ~10km +- layer 3: bit 270-333: units of ~0.15km + +Thus, the filter can be represented within 42 bytes per axis, or 84 bytes total. + + + +### Indexer scopes + +Indexers will declare the geopositional scope of their relevance. + +This would most likely be defined in layer 1 only. If an indexer only defines a single bit in layer 1, the protocol could advise that layer 2 is inspected for better granularity. And again the same with layer 2 and layer 3. + + +### Ask and bid scopes + +A store would define its origin in coordinates, from which a location filter bit field would be compiled. The scope should always be defined in terms layer 3. + +When the ask or bid is announced on the network, the forwarders and indexers can make a simple bitwise comparison to determine whether it matches its scope, and/or choose where to forward it to. This will localize the gossip and limit network congestion. + + +## Filter optimizations + +The filter could optionally be shortened by omitting the layer(s) that dont carry information (e.g. scope is only defined in terms of layer 1). + + +The network could maintain consensus on e.g. the max scope limit any indexer may provide, and/or whether the scopes must be contiguous. +If the max limit was 1 unit in layer 1, then the layer one could be represented by a single byte only, whose numeric value defines the single relevant sector. + +Similarily, if scopes must be contiguous, only two numeric values would be needed; one to define the offset and one to define the number of units. diff --git a/readlist.bibtex b/readlist.bibtex index 172ff0e..330b40a 100644 --- a/readlist.bibtex +++ b/readlist.bibtex @@ -141,3 +141,9 @@ url = "https://matheo.uliege.be/bitstream/2268.2/11657/12/thesis.pdf", urldate = "2022-02-26", } + +@MISC{ + author = "Wolfgang Nejdl and Boris Wolf and Changtao Qu and Stefan Decker and Michael Sintek Ambjörn Naeve and Mikael Nilsson and Matthias Palmer and Tore Risch", + title = "EDUTELLA: A P2P Networking Infrastructure Based on RDF", + year = "2001" +}