From 3404f8920e7175c4df662051dc18ea77d345a8f9 Mon Sep 17 00:00:00 2001 From: arkin0x Date: Fri, 8 Dec 2023 21:45:36 -0600 Subject: [PATCH] added details on how to handle values that are objects ref: https://github.com/nostr-protocol/nips/pull/927#issuecomment-1847897013 --- 44.md | 40 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 40 insertions(+) diff --git a/44.md b/44.md index 3f13e1b4..f604462b 100644 --- a/44.md +++ b/44.md @@ -51,6 +51,8 @@ A Place is comprised of two main parts: GeoJSON defines the geospatial structure ["prop", "opening_hours", "Mo-Fr_6:00-20:00,Sa-Su_6:00-17:00", "osm"], ["L", "schema/Place"], // specify usage of schema.org/Place namespace ["prop", "logo", "https://nostr.build/logo.png", "schema/Place"], + ["L", "schema/PostalAddress"], // specify usage of schema.org/PostalAddress namespace, even though this is technically also underneath schema/Place's `address` property: + ["prop", "addressCountry", "USA", "schema/PostalAddress"], ["admin", "5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36"] ["admin", "f7234bd4c1394dda46d09f35bd384dd30cc552ad5541990f98844fb06676e9ca"] ["g", "dtee7"], // geohash of place; should be as accurate as possible @@ -103,6 +105,44 @@ The `osm` [(Open Street Maps)](https://taginfo.openstreetmap.org/) and `schema/P Prop tags are __not__ indexed by relays. Props can be used for client-side filtering and interpretation of Places after they are queried from the relays; the `g` tag is the preferred method to query for Places in an area. + +#### How to Translate Props from Various Namespaces + +Some namespaces are hierarchical (including Schema) where a property may contain another collection of properties instead of a simple text value. An example of this is the `address` property of `schema/Place` which may be either text or a `schema/PostalAddress` object. If you wanted to specify individual properties of `PostalAddress`, you would do so like this: + +```javascript +"tags": [ + ["L", "schema/PostalAddress"], + ["prop", "addressCountry", "USA", "schema/PostalAddress"], + ["prop", "postalCode", "90743", "schema/PostalAddress"] +] +``` + +As you can see, these properties don't actually belong to `schema/Place`, even though `addressCountry` and `postalCode` can technically be considered a subproperty of the `address` property of `schema/Place`. Essentially, by specifying the _specific_ namespace, all properties can be represented in a flat key=value structure. This prevents the need to store anything but strict key=value strings in a `"prop"` tag. + +If a namespace has multiple levels of keys and you want to specify a lower one, you can do so like this. + +Imagine a fictional namespace called `kitchen`: +> - kitchen +> - blender - brand name of blender +> - fridge +> - status - true for on, false for off +> - freezer +> - __temperature - in degrees F__ +> - spaceAvailable - as a percentage of space left unused +> - toaster +> - status - true for on, false for off +> - cookTime - how long to cook in seconds +> +This is how we would specify a prop for the __temperature__ of the freezer: +> ```javascript +> "tags": [ +> ["L", "kitchen/fridge/freezer"], +> ["prop", "temperature", "34", "kitchen/fridge/freezer"] +> ] +> ``` +Because the `kitchen` namespace is not flat, we can traverse it with a `/` so that our prop only contains a simple key=value pair. + ### Admin Tags The Place creator can designate other pubkeys via `admin` tags. If these `admin` pubkeys publish kind `1754` events to apply properties to the Place, clients SHOULD give their props higher consideration than props applied by non-admin pubkeys.