nostr/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2024-09-20 06:45:49 -04:00
Code Issues Actions Packages Projects Releases Wiki Activity

added details on how to handle values that are objects

Browse Source 
ref: https://github.com/nostr-protocol/nips/pull/927#issuecomment-1847897013
This commit is contained in:
arkin0x 2023-12-08 21:45:36 -06:00
parent 47633879eb
commit 3404f8920e
1 changed files with 40 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

40
44.md
View File

@ -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.