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.