Re: [urn] Namespace application v3: reso

[Sam DeBord <[e-mail]>]

Could RESO receive an update on this namespace request? Thank you.

*Sam DeBord*
CEO | Real Estate Standards Organization <https://reso.org>
206.658.3225 | [e-mail]




On Tue, Aug 25, 2020 at 9:18 AM Sam DeBord <[e-mail]> wrote:

> Based on feedback from your members, please see the additional information
> here, as well as original application below.
>
> If there are any further insufficient items, please let us know ASAP and
> well will make adjustments.  Thank you.
>
> Additional information:
> *Unique Organizational Identifiers*
> RESO has existing systems which implement the concept of a *Unique
> Organizational Identifier
> <https://ddwiki.reso.org/display/DDW17/OUID+Resource>* (UOI). In this
> case, the goal is to enumerate the various organizations affiliated with
> RESO, both for identification purposes and for use in tracking their RESO
> certifications, given that we're a standards body.
>
> These would have the form urn:reso:uoi:<id>, where <id> is the assigned
> identifier in RESO's domain.
>
> "Organizations" can be multiple listing services, brokerages, or any other
> well-known vendor participating in the transaction. UOIs are used in the
> recording of events as a "recorder" of transactional real estate data, both
> in centralized and decentralized systems. We currently have about 800
> member organizations, representing the majority of real estate listing
> transaction originators and processors in the U.S., and are currently
> working to expand into other countries. We have an *event model* standard
> which is currently in DRAFT status and which furthers the notion of these
> entities as recorders.
>
>
> *Unique Licensee Identifiers*
> We are in the process of developing something called a *Unique Licensee
> Identifier* (ULI). These are a bit different than Unique Organizational
> Identifiers in the sense that currently in the United States there are
> identifiers assigned by the National Association of Realtors (NRDS numbers)
> that are supposed to uniquely identify any licensed Realtor-affiliated
> member.
>
> There are two issues here, a) they often have duplicate numbers and we're
> looking to de-duplicate these identifiers into a single, national ID that
> they can use when joining brokerages, tracking referrals, or creating
> transactions, and b) there are non-Realtor members who we'd like to assign
> licenses to as well, which include non-Realtor real estate agents and other
> service providers in the transaction such as photographers and assessors.
> Non-Realtor members are not supported within the NRDS framework. We intend
> to create a registry of these licensees.
>
> Their scheme would be urn:reso:uli:<id> where <id> is an identifier
> that's guaranteed to be unique within the RESO domain.
>
> ULIs would be used as part of a permanent record in a given transaction,
> either in centralized or decentralized systems, to identify the licensee
> (or subject) that participated in that transaction.
>
>
> *Change Tracking within Real Estate Transactions*
> The majority of RESO's member organizations produce detailed transactional
> histories when data change in their systems, and which are authoritative
> throughout the real estate industry and consumed by downstream data
> providers.
>
> RESO provides a standard Data Dictionary
> <https://ddwiki.reso.org/display/DDW17> which identifies well-known
> resources, fields, and enumerations, as well as various other metadata
> attached to these entities, and we certify member organizations for their
> conformance with this model. We're looking to catalog these items with URNs
> so they may be tracked in a reliable and uniform way and recorded during
> the transaction.
>
> For example, if there was a listing price change to a Property record in a
> given system, the transactional log would track that as a change to the
> following field: urn:reso:metadata:1.7:property:listprice, where 1.7 is
> the version of RESO's metadata that was used in that transaction. We also
> want to use these identifiers during the Certification process in order to
> record which metadata we found in a given applicant's metadata. We have
> several versions of metadata, and the URN would help us categorize the
> items for each version in a way that's clear to data consumers and
> producers.
>
> Resource, field, and enumeration-level metadata are intended to be used in
> RESO's Event Model as well, in conjunction with UOIs and ULIs, to record
> robust transactional histories when data change. These metadata identifiers
> would be used both by RESO members and by organizations external to our
> domain. This is one reason we'd like to use URNs for tracking these
> metadata, as they provide routing into RESO's ontology in a meaningful way.
>
> *Sam DeBord*
> CEO | Real Estate Standards Organization <https://reso.org>
> 206.658.3225 | [e-mail]
>
>
>
>
> On Sun, Mar 8, 2020 at 8:58 AM Sam DeBord <[e-mail]> wrote:
>
>> Please see resubmission of namespace application below.
>>
>> *Sam DeBord*
>> CEO | RESO - Real Estate Standards Organization
>> [e-mail] | 206.658.3225
>>
>> --
>>
>> Namespace Identifier:
>>
>>    reso
>>
>> Version:
>>
>>    0.1
>>
>> Date:
>>
>>    2020-03-08
>>
>> Registrant:
>>
>> Real Estate Standards Organization
>>
>> Sam DeBord, CEO
>>
>> [e-mail] – 919.504.9898
>>
>> Purpose:
>>
>> The Namespace Identifier (NID) "reso" for Uniform Resource Names
>> (URNs) will be used to identify resources published by Real Estate
>> Standards Organization: RESO <https://reso.org>.
>>
>>
>> These might include published standards or protocols that RESO
>> defines and that make use of URNs.  These namespaces are globally
>> unique.  The URN namespace will be used in public networks by clients to
>> configure and manage resources in the network.  Servers will enforce the
>> uniqueness of the namespaces by using the namespace and the XPath
>> associated with the managed node in the network when accessing a resource.
>>
>>
>>
>> Examples of proposed uses:
>>
>>
>>
>>
>> Representation of Unique Licensee IDs: These will have the form of
>> urn:reso:ulid:x, where x is a specific licensee identifier. Licensees can
>> be people like Agents, photographers, appraisers, and others involved in
>> the transaction.
>>
>>
>>
>> Recorder IDs: These are part of an event model proposal, in which the URN
>> will take a form of urn:reso:recorder:org:x, where org is an organization
>> id well-known to RESO and x is identifier of the recording entity in that
>> organization.
>>
>>
>>
>> References to RESO Data Dictionary items: These are already established
>> in our ecosystem. This link shows the "Property" resource, which consists
>> of fields and enumerations. Each field has a RESO-generated RecordID
>> associated with it (or LookupID in the case of enumerated values). For
>> example, the PropertySubType field has a RecordID of 100222, and one of the
>> allowed values for that field is Apartment, which is part of Lookup Field
>> ID 302000 and has LookupID 302001. These would have URNs of the form:
>> urn:reso:rid:100222, urn:reso:lfid:302000, and urn:reso:lid:302001,
>> respectively.
>>
>> Syntax:
>>
>>    The syntax of Namespace Specific Strings for the "reso" namespace
>>    is <NSS> in Uniform Resource Names (URNs) [RFC8141].
>>
>> The entire URN is case-insensitive.
>>
>> Assignment:
>>
>>    RESO will maintain the list of registered resources that use the
>>    "reso" NID in the "RESO URN Namespace" standards at
>>    <https://www.reso.org/>.
>>
>>    The RESO workgroups describe the <NSS>, how namespaces will be
>> allocated, and how experimental namespaces can
>>    be used within the allocated URN.
>>
>>    RESO will manage resource classes using the "reso" NID and will be
>>    the authority for managing resources and associated subsequent
>>    strings.  RESO will guarantee the uniqueness of the strings by
>>    validating them against the existing content of the standards.
>>    RESO may also permit secondary responsibility for certain defined
>>    resources.  Once a subtree assignment is made, it cannot be
>>    deleted or reassigned.
>>
>>    RESO may allow use of experimental type values in specific
>>    subtrees for testing purposes only.  Note that using experimental
>>    types may create collision as multiple users may use the same
>>    values for different resources and specific strings.  All
>>    experimentation must follow the guidance set forth in "A Uniform
>>    Resource Name (URN) Namespace for Examples" [RFC6963].
>>
>> Security and Privacy:
>>
>>    There are no additional security considerations other than those
>>    normally associated with the use and resolution of URNs in general.
>>
>> Interoperability:
>>
>>    There are no known interoperability issues at this time.
>>
>> Resolution:
>>
>>    It is not foreseen that URNs within this namespace will undergo
>>    resolution.
>>
>> Documentation:
>>
>>    Documentation can be found at
>>    <https://www.reso.org>
>>
>>
>>
>