Imported from registry/profiles/status/resource.md at commit 76a4a0c89924.

IRI Status Resource Profile

Profile URI: https://iri.science/profiles/status/resource
OpenAPI type: Resource
Status: Draft
Version: 1.0.0

1. Purpose

This document defines the semantic profile for an IRI Status Resource representation.

The canonical identifier for this profile is:

https://iri.science/profiles/status/resource

An IRI Resource represents physical, logical, virtual, or service-oriented infrastructure exposed through an IRI Facility API.

Resources may represent, for example:

• compute systems;
• compute nodes;
• CPUs or GPUs;
• storage systems;
• filesystems;
• network infrastructure;
• facility-hosted services;
• data-transfer services;
• inference services;
• websites or portals;
• other registered IRI resource types.

A Resource is distinct from:

• a Facility, which represents the organization providing the IRI Facility API;
• a Site, which represents the physical site associated with Resources;
• an Event, which records a timestamped occurrence involving a Resource;
• an Incident, which groups related Events and identifies Resources that may be affected;
• a Capability, which identifies an allocatable or otherwise distinguished capability associated with a Resource.

The normative structural definition of a Resource representation is provided by the IRI Facility API OpenAPI specification.

This profile supplements that schema with application-level semantics, resource-type interpretation rules, relationship conventions, and interoperability requirements.

2. Profile Semantics

An IRI Resource is an independently identifiable entity exposed by a participating Facility.

A Resource representation describes:

• the identity of the Resource;
• the semantic type of the Resource;
• descriptive metadata;
• the Site associated with the Resource;
• current reported status when available;
• Capabilities associated with the Resource;
• type-specific attributes where applicable;
• relationships to other IRI Resources;
• applicable operation entry points when advertised.

A Resource representation SHOULD provide sufficient hypermedia information for clients to discover related resources and applicable operations without requiring clients to infer API paths.

Clients MUST NOT infer related-resource URLs or operation entry points from:

• Resource identifiers;
• Resource Type URNs;
• Site identifiers;
• naming conventions;
• known Facility routing conventions;
• previously observed API paths.

When a relationship or operation entry point is advertised through _links, clients SHOULD use the advertised target.

3. Structural Contract

The structural definition of the Resource representation is defined by the IRI Facility API OpenAPI Resource schema.

The V2 Resource schema defines the following conceptual properties:

During the Phase 1 operation-affordance migration, supported_endpoints remains an optional array of broad endpoint categories under the existing OpenAPI contract. It is not a list of relation names, operation identifiers, or URLs, and this profile does not deprecate or remove it.

The OpenAPI schema is authoritative for:

• property names;
• JSON data types and structure;
• required and optional properties;
• nullable properties;
• additionalProperties behavior;
• formats;
• structural validation;
• read-only properties.

The DOE-IRI URN specification and DOE-IRI URN Registry are authoritative for:

• Resource Type URN syntax;
• registered Resource Type values;
• Resource Type hierarchy;
• registered parent-child relationships;
• delegated extension rules.

This profile is authoritative for additional semantic and interoperability conventions associated with the Resource representation.

4. Resource Identity

The id property identifies the Resource instance.

The identifier MUST be stable within the identifier scope established by the IRI Facility API.

Clients MUST treat id as an opaque Resource identifier unless another IRI specification explicitly defines additional semantics for that identifier.

The Resource instance identifier and the Resource Type URN serve different purposes.

For example:

{
  "id": "pioneer-compute",
  "resource_type": "urn:doe-iri:resource:compute:system"
}

means:

pioneer-compute
    ↓
identifies WHICH Resource instance

urn:doe-iri:resource:compute:system
    ↓
identifies WHAT KIND of Resource it is

Clients MUST NOT construct API URLs by combining the Resource identifier with assumed path templates.

For example, a client discovering:

{
  "id": "pioneer-compute"
}

MUST NOT assume the Resource is available at:

/api/v2/status/resources/pioneer-compute

or that job submission is available at:

/api/v2/compute/job/pioneer-compute

The canonical Resource URI and applicable operation entry points MUST instead be obtained from advertised URIs or hypermedia links.

5. Resource Classification

The resource_type property identifies the semantic type of the Resource.

The V2 resource_type property is structurally a string.

Its value MUST be an IRI Resource Type URN conforming to the DOE-IRI URN specification.

For example:

{
  "resource_type": "urn:doe-iri:resource:compute:system"
}

Resource types are not defined as a closed OpenAPI enumeration.

This allows the Resource taxonomy to evolve through the DOE-IRI URN Registry without requiring an OpenAPI schema revision whenever a new Resource subtype is introduced.

5.1 Resource Type Namespace

Shared Resource Type URNs are rooted at:

urn:doe-iri:resource

Examples include:

urn:doe-iri:resource:website
urn:doe-iri:resource:service
urn:doe-iri:resource:compute
urn:doe-iri:resource:system
urn:doe-iri:resource:storage
urn:doe-iri:resource:network
urn:doe-iri:resource:unknown

More-specific registered types narrow these classifications.

Examples include:

urn:doe-iri:resource:compute:system
urn:doe-iri:resource:compute:node
urn:doe-iri:resource:compute:cpu
urn:doe-iri:resource:compute:gpu

urn:doe-iri:resource:storage:system
urn:doe-iri:resource:storage:filesystem

urn:doe-iri:resource:service:dtn
urn:doe-iri:resource:service:inference

5.2 Hierarchical Semantics

Each additional semantic segment in a Resource Type URN narrows the meaning of the Resource type.

For example:

urn:doe-iri:resource:storage
        │
        └── filesystem

corresponds to:

urn:doe-iri:resource:storage

urn:doe-iri:resource:storage:filesystem

A Resource classified as:

urn:doe-iri:resource:storage:filesystem

is therefore also within the semantic hierarchy rooted at:

urn:doe-iri:resource:storage

because that parent hierarchy level is registered and semantically defined.

5.3 Producer Requirements

A producer SHOULD emit the most specific registered Resource Type URN that accurately describes the Resource.

For example, a scratch filesystem SHOULD use the registered filesystem Resource Type and identify its scratch tier through the applicable type-specific attributes:

{
  "resource_type": "urn:doe-iri:resource:storage:filesystem",
  "attributes": {
    "tier": "urn:doe-iri:storage:tier:scratch"
  }
}

The Resource Type identifies the Resource as a filesystem; the tier attribute identifies its intended scratch lifecycle or usage tier.

A producer MAY emit a recognized parent Resource Type when:

• a more-specific subtype is unavailable;
• a more-specific subtype is not applicable;
• disclosure of the subtype is restricted;
• the implementation intentionally exposes only a broader classification.

A producer MUST NOT invent an unregistered shared Resource Type URN and present it as a canonical DOE-IRI type.

Facility- or project-specific Resource types MUST use the DOE-IRI delegated-extension mechanism when an appropriate delegated scope exists.

5.4 Consumer Requirements

A generic client MUST NOT reject an otherwise syntactically valid IRI Resource Type URN solely because the specific type is not known to the client’s local implementation.

A hierarchy-aware client SHOULD fall back to the nearest recognized semantic parent.

For example, if a client does not understand:

urn:doe-iri:resource:storage:filesystem

but understands:

urn:doe-iri:resource:storage

it SHOULD fall back to generic storage behavior where that behavior is applicable.

A client that does not implement DOE-IRI hierarchy parsing MUST treat an unfamiliar Resource Type URN as an opaque semantic identifier.

5.5 Hierarchy Matching

Hierarchy-aware matching MUST operate on complete colon-delimited semantic segments.

For example:

urn:doe-iri:resource:storage

is a semantic parent of:

urn:doe-iri:resource:storage:filesystem

but:

urn:doe-iri:resource:stor

is not a semantic parent.

Clients MUST NOT use arbitrary string-prefix comparison as a substitute for DOE-IRI hierarchy-aware matching.

5.6 Extension Resource Types

DOE-IRI extension Resource Type URNs use the explicit ext delegation form.

For example:

urn:doe-iri:resource:compute:ext:nersc:fpga

An extension marker and authority code express delegation structure rather than additional shared semantic hierarchy.

For hierarchy-aware fallback, clients stop at the nearest recognized shared semantic parent before ext.

For example:

urn:doe-iri:resource:compute:ext:nersc:fpga

may fall back to:

urn:doe-iri:resource:compute

A producer claiming an assigned DOE-IRI extension MUST satisfy the applicable syntax, scope-authorization, and local-definition requirements of the DOE-IRI URN specification.

6. Current Status

The current_status property represents the current status reported for the Resource.

The IRI Status model defines the following status values:

up
down
degraded
unknown

For example:

{
  "current_status": "degraded"
}

current_status provides a current-state summary associated with the Resource.

It is distinct from Event history.

An Event records a Resource condition at the Event’s occurred_at time, while current_status describes the current reported condition of the Resource representation.

The existence of:

{
  "current_status": "up"
}

does not imply that:

• the Resource has never experienced an Incident;
• every operation associated with the Resource is currently usable;
• every dependent Resource is available;
• every endpoint associated with the Resource is reachable.

Clients requiring historical information SHOULD inspect applicable Event and Incident representations.

7. Site Association

Each Resource has one authoritative Site association under the current V2 contract.

The representation exposes this relationship through:

site_uri

The registered IRI hypermedia relation is:

iri:located-at

with canonical relation URI:

https://iri.science/rels/located-at

Conceptually:

Resource  -- iri:located-at -->  Site
   1                1

iri:located-at identifies the relatively stable physical and administrative Site associated with the Resource.

It MUST NOT be interpreted as asserting:

• current process placement;
• compute hosting;
• service reachability;
• operational health;
• current availability;
• ownership;
• live network routing.

The target Site representation MAY advertise:

https://iri.science/profiles/facility/site

as its representation profile.

8. Capabilities and Type-Specific Behavior

8.1 Capabilities

The Resource representation exposes associated Capabilities through:

capability_uris

The registered IRI hypermedia relation is:

iri:has-capability

with canonical relation URI:

https://iri.science/rels/has-capability

Conceptually:

Resource  -- iri:has-capability -->  Capability
   1                  0..*

A Capability identifies a capability associated with the Resource.

The existence of a Capability relationship MUST NOT itself be interpreted as:

• an authorization grant;
• an allocation;
• current availability;
• permission to invoke an operation;
• a guarantee that the Capability can currently be consumed.

8.2 Resource Definition Profiles

The common Resource profile defines semantics applicable to every IRI Resource representation. When the Resource Type Registry associates the exact resource_type with a Resource Definition Profile, that registered mapping selects the additional type-specific semantics that apply.

A Resource Definition Profile supplements this common profile. It defines type-specific semantics and MAY define attributes, relationships, and operation affordances applicable to the Resource type. When attributes is non-null, its members are interpreted according to the applicable Resource Definition Profile.

For example:

{
  "resource_type":
    "urn:doe-iri:resource:compute:system"
}

is mapped by the Resource Type Registry to:

https://iri.science/profiles/resource-definition/compute/system

The registered mapping in Resource Type URNs is authoritative; clients MUST NOT construct a Resource Definition Profile URI by transforming the Resource Type URN.

A Resource Definition Profile specializes the existing IRI v2 Resource representation. It does not replace the common Resource representation and does not create a separate IRI v2 Resource Definition API object or endpoint.

A generic client MUST remain capable of processing the common Resource representation even when it does not understand the Resource’s most-specific type or applicable Resource Definition Profile. Such a client MAY treat unfamiliar attributes content as opaque JSON data.

8.3 Resource Type Does Not Define URLs

A Resource Type URN identifies what the Resource is.

It does not identify where related resources or operations are located.

For example:

urn:doe-iri:resource:compute:system

does not imply that job submission is located at:

/api/v2/compute/job/{resource_id}

The applicable operation MUST be discovered through an advertised operation relation when such a relation is available.

9. Hypermedia Representation

When represented using HAL, a Resource SHOULD advertise its identity, relationships, and applicable operation entry points through _links.

For example:

{
  "id": "pioneer-compute",
  "name": "Pioneer Compute System",
  "last_modified": "2026-08-17T18:12:00Z",
  "resource_type": "urn:doe-iri:resource:compute:system",
  "current_status": "up",
  "supported_endpoints": ["compute"],

  "_links": {
    "self": {
      "href":
        "https://api.example.org/api/v2/status/resources/pioneer-compute",
      "type": "application/hal+json",
      "profile": "https://iri.science/profiles/status/resource"
    },

    "curies": [
      {
        "name": "iri",
        "href": "https://iri.science/rels/{rel}",
        "templated": true
      }
    ],

    "iri:located-at": {
      "href":
        "https://api.example.org/api/v2/facility/sites/example-site",
      "title": "Example Facility Site",
      "type": "application/hal+json",
      "profile": "https://iri.science/profiles/facility/site"
    },

    "iri:has-capability": [
      {
        "href":
          "https://api.example.org/api/v2/account/capabilities/pioneer-gpu",
        "title": "Pioneer GPU Capability",
        "type": "application/hal+json",
        "profile": "https://iri.science/profiles/account/capability"
      }
    ],

    "iri:submit-job": {
      "href":
        "https://api.example.org/api/v2/compute/job/pioneer-compute"
    },

    "service-desc": {
      "href": "https://api.example.org/openapi.json",
      "type": "application/vnd.oai.openapi+json;version=3.1"
    }
  }
}

In this representation:

• resource_type identifies what the Resource is;
• self identifies the Resource representation;
• iri:located-at identifies the associated Site;
• iri:has-capability identifies associated Capabilities;
• iri:submit-job identifies an applicable operation entry point;
• service-desc identifies the applicable deployed OpenAPI description, which binds https://iri.science/rels/submit-job to its Operation Object through x-iri-relation;
• profile identifies the semantic profile of a target representation.

These identifiers serve different purposes and MUST NOT be treated as interchangeable.

10. Relationship URIs and Operation Affordances

IRI-specific relations use the IRI CURIE namespace.

For example:

{
  "name": "iri",
  "href": "https://iri.science/rels/{rel}",
  "templated": true
}

The CURIE:

iri:located-at

expands to:

https://iri.science/rels/located-at

and:

iri:has-capability

expands to:

https://iri.science/rels/has-capability

The applicable canonical relation documents define the normative semantics of those relationships.

This Resource profile MUST NOT redefine those link-relation semantics.

10.1 Operation Discovery

A Resource MAY advertise operation entry points applicable to that Resource.

For example, a Resource classified as:

urn:doe-iri:resource:compute:system

may advertise:

{
  "_links": {
    "iri:submit-job": {
      "href":
        "https://api.example.org/api/v2/compute/job/pioneer-compute"
    },
    "service-desc": {
      "href": "https://api.example.org/openapi.json",
      "type": "application/vnd.oai.openapi+json;version=3.1"
    }
  }
}

The Resource Type URN and operation relation answer different questions:

resource_type
    ↓
WHAT is this Resource?

urn:doe-iri:resource:compute:system


iri:submit-job
    ↓
WHAT operation is applicable and WHERE?


service-desc
    ↓
HOW is that operation invoked?

An operation link does not itself define:

• HTTP method;
• request body;
• response body;
• authentication;
• authorization;
• scheduling policy;
• operational success.

Those invocation semantics remain defined by the applicable machine-readable API contract, such as OpenAPI.

When a Resource advertises an operation-affordance relation adopted by the operation-affordance RFC, it MUST also advertise at least one applicable service-desc link. The deployed OpenAPI description identified by that link MUST contain an x-iri-relation binding from the operation’s canonical relation URI to the applicable Operation Object.

Clients use the registered relation to determine why the operation applies, the advertised href to locate it, and the bound deployed OpenAPI Operation Object to determine the method, parameters, request body, responses, errors, and security requirements. Clients MUST NOT infer those details from the relation name or probe a mutation to discover them.

An operation-affordance link targets an operation entry point rather than an IRI representation. It MUST NOT carry an IRI representation profile.

Clients MUST NOT infer an operation URI solely from resource_type.

10.2 Phase 1 Coexistence with supported_endpoints

Phase 1 retains supported_endpoints with its existing optional category semantics. When that property is present on a Resource:

• advertising a registered compute-family operation relation requires "compute" in the array;
• advertising a registered filesystem-family operation relation requires "filesystem" in the array;
• storage-discovery relations have no legacy category mapping.

The reverse implication does not apply. A retained category does not require any individual operation link, including when a link is authorization-filtered or its adapter operation is not implemented for the represented context. Authorization-suppressed links therefore do not make a retained category inconsistent.

Producers MUST NOT replace category values with relation names, operation identifiers, or URLs. Clients MUST NOT construct or infer an operation link from a category. Deprecation or removal of supported_endpoints requires a separately approved later compatibility revision.

10.3 Generic Compute and Storage Resource Types

The exact generic Resource Types:

urn:doe-iri:resource:compute
urn:doe-iri:resource:storage

are governed by this common Resource profile; this profile does not create generic compute or storage Resource Definition Profiles.

Generic compute and storage Resources are conditionally eligible only for the filesystem and storage-location relations whose registered definitions permit the exact generic type, and only when the actual adapter semantics and operation context are explicit and unambiguous. Generic storage may also advertise registered storage-access-endpoint discovery where implemented. Generic compute is not eligible for compute-job relations.

Operation eligibility is exact-type-based. Eligibility of a generic or parent type MUST NOT be inherited automatically by descendants such as compute CPU or GPU Resources, storage systems, block storage, or object storage. Each registered relation definition remains authoritative for its complete source matrix and context requirements.

11. Relationship to Existing URI Properties

The current V2 Resource schema defines:

self_uri
site_uri
capability_uris

These properties expose Resource and related-resource URIs directly.

When the IRI HAL hypermedia model is used, the corresponding relationships SHOULD be represented through _links:

self_uri
    ↓
_links.self

site_uri
    ↓
_links["iri:located-at"]

capability_uris
    ↓
_links["iri:has-capability"]

For example:

{
  "self_uri":
    "https://api.example.org/api/v2/status/resources/pioneer-compute",

  "site_uri":
    "https://api.example.org/api/v2/facility/sites/example-site",

  "capability_uris": [
    "https://api.example.org/api/v2/account/capabilities/pioneer-gpu"
  ],

  "_links": {
    "self": {
      "href":
        "https://api.example.org/api/v2/status/resources/pioneer-compute",
      "profile": "https://iri.science/profiles/status/resource"
    },

    "iri:located-at": {
      "href":
        "https://api.example.org/api/v2/facility/sites/example-site",
      "profile": "https://iri.science/profiles/facility/site"
    },

    "iri:has-capability": [
      {
        "href":
          "https://api.example.org/api/v2/account/capabilities/pioneer-gpu",
        "profile": "https://iri.science/profiles/account/capability"
      }
    ]
  }
}

During the compatibility period:

1. Producers retain the required self_uri, site_uri, and capability_uris properties.
2. Producers MAY additionally expose corresponding HAL relationships.
3. Whenever site_uri and _links["iri:located-at"] are both present, the link href MUST exactly equal site_uri.
4. Whenever capability_uris and _links["iri:has-capability"] are both present, they MUST identify the same targets, disregarding order.
5. Consumers SHOULD prefer advertised hypermedia relations and MAY fall back to corresponding URI-valued properties.
6. Removing or changing existing URI properties requires a separate OpenAPI schema revision.
7. self_uri remains authoritative under the current OpenAPI contract until changed by an approved schema revision.

Clients implementing the HAL representation SHOULD use advertised _links for navigation rather than constructing URLs from identifiers or Resource Type URNs.

12. Media Type

This profile identifies the semantics of the Resource representation independently of a particular serialization.

When a Resource is represented using HAL JSON, the representation SHOULD use:

application/hal+json

and MAY identify this profile where appropriate:

https://iri.science/profiles/status/resource

The profile URI does not replace the media type or Resource Type URN.

The three identifiers have distinct roles:

application/hal+json
    ↓
HOW the representation is encoded

https://iri.science/profiles/status/resource
    ↓
WHAT semantic representation contract applies

urn:doe-iri:resource:storage:filesystem
    ↓
WHAT KIND of IRI Resource is represented

These identifiers MUST NOT be treated as interchangeable.

13. Static and Dynamic Semantics

A Resource representation may contain both relatively stable descriptive information and dynamic status information.

Relatively stable information typically includes:

id
name
description
group
resource_type
site_uri
capability_uris
supported_endpoints

Dynamic information includes:

current_status
last_modified

The attributes object is not categorically static or dynamic. The applicable Resource Definition Profile defines whether each type-specific value represents configuration, capability, descriptive metadata, a measured or quantitative value, a time-varying observation, or another type-specific concept.

Type-specific attributes MUST NOT duplicate or override current_status, which remains the common top-level property for the current reported Resource condition.

Relationships such as:

iri:located-at
iri:has-capability

generally describe relatively stable topology or administrative association.

Their existence MUST NOT be interpreted as proof of current availability or operational health.

Operation affordances MAY be more dynamic.

The presence of an operation link indicates that the operation is applicable and discoverable in the current representation context.

It does not guarantee that invocation will succeed.

Clients SHOULD consult the current Resource representation before acting on an operation affordance rather than relying on cached, indexed, or previously observed links.

14. Authorization and Visibility

Authorization MAY affect information and relationships visible through a Resource representation.

A provider MAY omit:

• Capabilities;
• operation affordances;
• topology relationships;
• type-specific attributes;
• descriptive information;
• other optional links

when the requester is not authorized to discover that information, subject to requirements imposed by the applicable OpenAPI schema and relation definitions.

A producer MAY expose a broader parent Resource Type when disclosure of a more-specific subtype is intentionally restricted.

For example:

urn:doe-iri:resource:storage

may be exposed instead of:

urn:doe-iri:resource:storage:filesystem

when policy permits disclosure of the broad Resource class but not the more-specific subtype.

The absence of an operation link MUST NOT necessarily be interpreted as proof that the underlying Resource has no such operation.

It indicates only that the operation is not advertised in the current representation context.

Where legacy URI properties and corresponding HAL relationships are both returned, they MUST remain consistent.

15. Conformance

A representation conforms to the IRI Status Resource Profile when:

1. it conforms to the applicable IRI Facility API Resource schema;
2. its properties are interpreted according to the IRI Facility API and this profile;
3. resource_type is structurally represented as a string;
4. resource_type contains a Resource Type URN conforming to the DOE-IRI URN specification;
5. Resource Type URNs are interpreted according to the applicable DOE-IRI registry semantics;
6. unfamiliar but syntactically valid Resource Type URNs are not rejected solely because they are absent from local client code or generated models;
7. hierarchy-aware Resource Type matching operates on complete semantic segments;
8. clients use nearest-recognized-parent or opaque fallback behavior where appropriate;
9. Resource identifiers are treated as identifiers rather than URL templates;
10. Resource Type URNs are treated as semantic classifications rather than URL or operation templates;
11. current_status is distinguished from historical Event state;
12. the authoritative Site is discoverable through site_uri or iri:located-at;
13. associated Capabilities are discoverable through capability_uris or iri:has-capability;
14. IRI-specific link relations use the canonical IRI relation namespace;
15. representation profile URIs are not used as substitutes for Resource Type URNs or link-relation identifiers;
16. when both site_uri and _links["iri:located-at"] are present, they identify the same target;
17. when both capability_uris and _links["iri:has-capability"] are present, they identify the same targets;
18. applicable operation entry points are discovered through advertised links rather than inferred from Resource identifiers or Resource Type URNs;
19. clients are not required to infer or construct related-resource or operation URLs;
20. when a Resource Definition profile applies, it supplements this common profile and does not replace it;
21. every advertised adopted operation-affordance relation has an applicable service-desc whose deployed OpenAPI contains the matching canonical x-iri-relation binding;
22. operation-affordance links do not carry IRI representation profiles;
23. when supported_endpoints is present, visible compute-family and filesystem-family links have the corresponding category, without requiring the reverse implication;
24. storage-discovery relations are not assigned a supported_endpoints category; and
25. generic compute and storage operation eligibility is applied only to exact types under the applicable registered relation and explicit adapter-context rules, never inferred through the Resource Type hierarchy.

A conforming representation MAY contain additional properties and links where permitted by the applicable IRI API specification.

16. Profile Identification

The canonical identifier for this profile is:

https://iri.science/profiles/status/resource

The profile URI is a stable semantic identifier.

Repository paths, GitHub URLs, OpenAPI document locations, Resource Type URNs, and documentation-generation URLs MUST NOT be substituted for this canonical identifier.

The canonical URI SHOULD resolve to documentation describing this profile.

17. Versioning

The profile version identifies the revision of this profile document.

Compatible editorial clarifications, new registered Resource Type URNs, and backward-compatible semantic additions MAY retain the same profile URI.

Adding a new Resource Type URN to the DOE-IRI URN Registry does not require a new version of this Resource representation profile merely because the taxonomy has expanded.

Changes that materially alter the interpretation or processing semantics of the common Resource representation SHOULD be evaluated for compatibility before incorporation into the existing profile.

The canonical profile URI SHOULD remain stable across compatible revisions.

DOE Integrated Research Infrastructure — Status Resource Profile