PropertyType and PropertySubType

[bryanburgers]

On the README.md here it says as some of the options:

• propertytype is an optional Data Dictionary type, in this case Residential
• subpropertytype is empty in this case

At RESO Fall 2023 I asked a question regarding this and my concerns that including this makes the spec much less “universal” because two MLSes can refer to the same property, but have different property types.

@mlesswing seemed to indicate that the UPI doesn’t include Data Dictionary elements, only real property according to governmental entities and non-real sub properties.

Should this be clarified here? Do these PropertyType/PropertySubType Data Dictionary types need to be removed?

[darnjo]

The scheme according to v2 is just an Internet-friendly envelope for encoding DD data which preserves the source data.

We have some flexibility on how to define which things are required or not, and welcome further input.

In the non-hashed versions, providers and consumers could come up with their own strategies to match on the components, the important thing is that relevant ones are conveyed in a predictable way.

[darnjo]

Specifically, regarding this point about PropertyType and PropertySubType:

At RESO Fall 2023 I asked a question regarding this and my concerns that including this makes the spec much less “universal” because two MLSes can refer to the same property, but have different property types.

The goal is to have the UPI refer to the real property, not the listing. However, other pieces of DD information could be encoded into the URN-based UPI, and users of this data could look at it through different lenses. If only real property, look at these components, for other things look at these components (which may include even local data).

[bryanburgers]

Ah, OK. Let me repeat back what I hear to make sure I understand.

My previous expectation: UPIs should be comparable by string. If MLS1 gives a v2 UPI and MLS2 gives a v2 UPI, I can know whether those are the same UPI by comparing the strings that are received.

Roughly what you're saying: UPIs should be parsed to be compared. If MLS1 gives a v2 UPI and MLS2 gives a v2 UPI, I can know whether those are the same UPI by parsing and comparing the important fields. Each MLS is allowed to provide additional data within the UPI.

I don't want to put words in your mouth though; does that roughly match what you're saying?

[darnjo]

Ideally they would be comparable by string. And if all the parts are truly there and match between providers they would be. But, we all know how these data sets can be sometimes. ;)

If the groups can pass testing rules so that we actually require certain components to be there, if the data is really present, that might help.

Like, you must have Country, StateOrProvince, County (and its analogues in other countries), and Parcel Number -- that might go a long way. With some of the options, like PropertyType or SubParcelNumber, that data can be conveyed, if relevant, but for anyone relying on the other parts they would be reliable (well, as much as the data is reliable).

However, when exact matching doesn't work, you also have the components so you could potentially try your own heuristics on matching on parts, similar to AWS when there's a * in a resource name (ARN). And, since v2 preserves source data, people could try doing an exact match first, then use other techniques to try and get them to link up if that doesn't work.

One thing it might be nice to have is the Provider Unique Org Id (UOI) so you know the source.