The initial, DP0.2 image services are using URIs of the form "butler://dp02" in the construction of ID strings to be exchanged between the services.

This is a temporary stopgap before agreeing on conventions for standards-compliant IVOIDs to be used in these services.  IVOIDs are defined by the "IVOA Identifiers" standard, currently at Version 2.0.

In particular, the obs_creator_did (site-independent dataset identifier) and obs_publisher_did (site-dependent identifier) from the ObsCore data model are intended to be IVOIDs (and this is where we are currently using "butler:" strings as a stopgap).

IVOIDs are URIs; they must begin, following their "ivo:" scheme declaration, with an "authority" component (see Section 2.3.2 of the standard).

Some excepts:

A naming authority is an organization (usually a data provider) that has been granted the right by the IVOA to create IVOA-compliant identifiers for resources it registers. See sect. 3 for details on how this right is granted. The naming authority creates IVOIDs with empty local parts within the scope of one or more authority identifiers.

While the syntax for the authority identifiers allows it to look just like a DNS hostname, current convention discourages this practice to avoid the suggestion that an IVOA Identifier can be resolved like a common http URL. As of this writing, the convention of the US Virtual Astronomical Observatory (VAO) is hierarchical naming that combines the publishing organization name with the project or archive (e.g. "adil.ncsa") while leaving out fields like ".edu" or ".org". In the AstroGrid project, the convention is to use a DNS name in reverse order (e.g. "org.astrogrid.www"); this practice has the advantage of reducing the probability that two organizations will want to use the same authority identifier.

And then, in the referenced Section 3 (Creating Identifiers), it says:

[only] recognized naming authorities (or persons representing such organizations) may create [the authority and pathname components of IVOIDs].
The details of the service used to claim a naming authority is described in the IVOA Registry Interfaces standard (Benson et al., 2015).
Once an organization is recognized as a naming authority, it is free to register any number of resources with identifiers having an authority identifier that they control. No organization may create an identifier with an authority identifier it does not control.

The Registry Interfaces standard v1.1 says, in essence, that claiming a naming authority is done by publishing a vg:Authority record in a known Registry. Clearly we are not ready to run our own Registry yet, but an initial step would be for us to choose a sensible authority.

Finally, from the IVOA Identifiers standard:

A naming authority is allowed to control multiple authority identifiers to organize related resources into different namespaces. For example, an organization may choose to control two authority identifiers, one for research-related resources and one for education/outreach resources, even though they are all maintained by the same organization and perhaps made available through the same machine.

So, we might possibly want to do just this: have one for the DM-provided science data products and one for EPO.

We also need to determine whether we will use the same authority for obs_publisher_did to represent datasets published through the USDF as we use for obs_creator_did to represent datasets of ours regardless of where physically published. If we do use the same authority for both, then the rest of these IVOIDs will have to display the difference between the two. If we want to use different authorities, perhaps the former could suggest "Vera Rubin Observatory" while the latter suggests "LSST" in its new meaning.

We're deferring this problem until after DP0.2, but it can't be put off further.