General questions from Gridraven

[catkins-miso]

• How does this schema map to or work with CIM? Please see https://trolie.energy/community-events/20240221-Intro-to-TROLIE.html#how-does-cim-relate-to-the-trolie-specification
• Use/recommend to use urn prefix for mrid and eic ala urn:uuid: or urn:eic: This is an excellent suggestion, thank you. I'll create a task to make appropriate updates to our documentation.
• General recommendation, do not use resource-id to encode information, Would you clarify this recommendation?
• extend schema with dedicated fields:
  1. In and out of service, This is something we should explore further. We need to identify which interop use cases in the TROLIE scope would make use of this. Currently, there's no means to indicate that the Ratings Provider believes a Ratings Obligation is obviated by an outage at runtime. We do support temporary AAR exceptions to propose a static rating rather than a dynamic rating for some period of time.
  2. Direction of limits, from to bus, etc. I believe @getorymckeag will address this in How to represent directional ratings / ratings at terminals? #235

[Haigutus]

3. General recommendation, do not use resource-id to encode information

Encoding information to resource id, is bad idea, because then the field becomes multipurpose and you are actually encoding information to a long string, that then needs to be parsed. Once that pattern happens, different parsing rules need to be agreed upon between parties or standardized centrally.

Better approach is to have some metadata section/solution, where this can be expressed without abusing the resource-id, similar as you have defined flexible and optional solutions for "alternative-idetifiers" and "inputs-used"

Current examples in spec

Parser spec <resource_id>-, can use both split("-") or suffix("-in"/"-out")

      "power-system-resources": [
          { "resource-id": "segmentA-in" },
          { "resource-id": "segmentA-out" }

Parser spec <resource_id_from>-<resource_id_to>, can use split("-")

      "power-system-resources": [
          { "resource-id": "BusA-BusB" },
          { "resource-id": "BusB-BusA" }

Parser spec <resource_id>-<resource_status>, cant use split, needs to use suffix check and then substraction to get ID

    "power-system-resources": [
      {
        "resource-id": "8badf00d-145-in-service",
        "alternate-identifiers": [
          {
            "name": "EMS.Name.145-in-service",
            "authority": "TO-NERC-ID"
          }
        ]
      },
      {
        "resource-id": "8badf00d-145-out-of-service",
        "alternate-identifiers": [
          {
            "name": "EMS.Name.145-out-of-service",
            "authority": "TO-NERC-ID"
          }

[Haigutus]

Just to highlight - you could have a mess like this (in my mind), that needs to be parsed

if one use both directions and status together

• EMS.Name.145-in-out-of-service
• EMS.Name.145-out-out-of-service
• EMS.Name.145-in-in-service
• EMS.Name.145-out-in-service

[catkins-miso]

From the community call, I wanted to recap the response on resource-id.

The gist is that the TROLIE spec is only able to make a recommendation on what the parties should use as a primary identifier, i.e., mRID. The use of composite identifiers is in common practice and is the prerogative of the Clearinghouse Provider in the most common use cases. We support alternate names to help bridge the gap between a unifying naming standard as well as vendor extensions (additional-data) and inputs-used to include data that explicitly represents information that is also encoded into composite identifiers.

That said, the spec is largely agnostic to topology considerations and does not have semantics suitable for representing things like breaker statuses.

Ultimately pre-coordination between Ratings Providers and Clearinghouse Providers of Ratings Obligations for Power System Resources involves agreeing on how those Power System Resources are nominated, i.e., the resource-id that uniquely identifies them. This specification assumes that this pre-coordination would be used whenever topological considerations would require concomitant ratings proposals for the same facility under different configurations. See Directional Ratings and Network Elements Names and Naming Authorities.