Re: [urn] Namespace application v3: reso

[Sam DeBord <[e-mail]>]

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