mirror of
https://github.com/nostr-protocol/nips.git
synced 2024-12-23 17:05:51 -05:00
added details on how to handle values that are objects
ref: https://github.com/nostr-protocol/nips/pull/927#issuecomment-1847897013
This commit is contained in:
parent
47633879eb
commit
3404f8920e
40
44.md
40
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"],
|
["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
|
["L", "schema/Place"], // specify usage of schema.org/Place namespace
|
||||||
["prop", "logo", "https://nostr.build/logo.png", "schema/Place"],
|
["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", "5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36"]
|
||||||
["admin", "f7234bd4c1394dda46d09f35bd384dd30cc552ad5541990f98844fb06676e9ca"]
|
["admin", "f7234bd4c1394dda46d09f35bd384dd30cc552ad5541990f98844fb06676e9ca"]
|
||||||
["g", "dtee7"], // geohash of place; should be as accurate as possible
|
["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.
|
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
|
### 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.
|
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.
|
||||||
|
|
Loading…
Reference in New Issue
Block a user