Skip to main content
Version: 0.5.1

Semantic Web Guide for URPX

Version: 0.5.1 (Working Group Draft) Last Updated: 2026-10-05

A beginner-friendly introduction to semantic web technologies for the URPX working group

Table of Contents​

  1. Why Semantic Web for Rate Plan Data?
  2. Semantic Web 101
  3. Core Technologies
  4. Learning Resources
  5. Next Steps

Why Semantic Web for Rate Plan Data?​

The Physical-World-to-Bill Connection​

Rate plan data bridges two worlds:

  • Physical World: Kilowatt-hours consumed, peak demand measured, time periods tracked
  • Financial World: Line items on bills, charges calculated, costs allocated

This connection requires rich semantics to accurately represent:

  • Conditions (time-of-use, seasonal variations)
  • Eligibility rules (customer qualifications, program enrollment)
  • Geographic applicability (service territories, jurisdictions)
  • Regulatory context (tariff filings, approval dates)

Flat file formats (CSV, plain JSON) carry no standardized meaning for these relationships, so each consumer re-derives it. Semantic web technologies give the relationships a shared vocabulary and a graph form that machines can read across systems.

Machine Learning Applications​

Semantically rich, interconnected data also serves machine learning applications:

Intelligent Rate Plan Comparison

  • Language models can read rate plan structure relationships
  • Contextual recommendations based on usage patterns
  • Automated rate plan analysis across utilities

Customer-Specific Optimization

  • Machine learning on knowledge graphs
  • Cost optimization considering time-of-use and tiers
  • Personalized rate plan recommendations

Regulatory Compliance

  • Automated validation of rate plan structures
  • Identification of compliance issues
  • Cross-jurisdictional analysis

Market Analysis

  • Pattern recognition across rate plans
  • Regional pricing trend identification
  • Competitive rate plan structure analysis

Semantic Web 101​

What is the Semantic Web?​

The semantic web represents data as interconnected graphs of meaning, not just isolated records.

Traditional Approach (Tables/JSON):

{
  "price_id": "PRC-001",
  "type": "energy",
  "price": 0.12,
  "unit": "kWh"
}

Semantic Web Approach (Linked Data with JSON-LD):

{
  "@context": [
    "https://urpx.org/ns/context/releases/v0.5.1/jsonld/urpx-context.jsonld",
    { "ex": "https://example.com/" }
  ],
  "@id": "ex:PRC-001",
  "@type": "urpx:Price",
  "urpx:chargeType": {"@id": "urpx:usageCharge"},
  "urpx:chargeCategory": {"@id": "urpx:auxiliaryCharge"},
  "urpx:unitPrice": "0.12",
  "urpx:hasMetricSpecification": {
    "@type": "urpx:MetricSpecification",
    "urpx:commodity": {"@id": "urpx:electricity"},
    "urpx:measurementKind": {"@id": "urpx:energy"},
    "urpx:unitOfMeasure": {"@id": "urpx:kWh"}
  }
}

Notice how the semantic version explicitly links the charge to:

  • Its type via IRI reference (urpx:usageCharge)
  • Its measurement specification with commodity, kind, and unit
  • Enumeration values are dereferenceable IRIs that machines can follow

Machines can follow these links to understand relationships and answer complex questions.

RDF: The Foundation​

RDF (Resource Description Framework) expresses data as triples:

Subject → Predicate → Object

Every statement has three parts:

Example 1: Simple Property

:PRC-001 → urpx:unitPrice → 0.12
(This price) (has unit price) (0.12)

Example 2: Relationship

:VERSION-2025 → urpx:forRatePlan → :RES-TOU-2025
(This version snapshot) (is for rate plan) (RES-TOU-2025)

Example 3: Type Declaration

:PRC-001 → rdf:type → urpx:Price
(PRC-001) (is a) (Price)

Graph Structure​

A simple rate plan forms an interconnected graph. This structure enables:

  • Navigation: Follow links to find related data
  • Inference: Deduce new facts from relationships
  • Validation: Check structural constraints
  • Querying: Ask complex questions across the graph

Benefits Over Flat Formats​

1. Explicit Relationships

  • No ambiguity about how data connects
  • Machine-understandable semantics
  • Self-documenting structure

2. Extensibility

  • Add new properties without breaking existing data
  • Multiple standards can reference the same entities
  • Modular ontology design

3. Integration

  • Different systems can map to the same concepts
  • Cross-standard queries possible
  • Reduces integration complexity

4. Validation

  • Structural constraints enforced
  • Data quality rules automated
  • Consistency across datasets

Core Technologies​

Ontologies (OWL)​

What They Are

An ontology is a formal specification of a domain's concepts and relationships. Think of it as a "data dictionary with superpowers."

URPX Ontology Structure:

  • Classes: RatePlan, RatePlanVersion, PricingModel, Price, TOUSchedule, Season, Organization
  • Properties: hasPrice, chargeType, unitPrice, effectiveDate, forRatePlan
  • Relationships: Prices belong to PriceSets, and PriceSets belong to RatePlanVersions through the Prices container; versions link back to their plan identity via forRatePlan
  • Constraints: Every RatePlanVersion must name its plan (forRatePlan) and declare a CoverageClaim

Why We Use OWL:

  • W3C Standard: Globally recognized and widely supported
  • Reasoning: Machines can infer facts such as class membership through subclass relations
  • Validation: Structural constraints ensure data quality
  • Interoperability: Common vocabulary across systems

Example OWL Definition:

@prefix urpx: <https://urpx.org/ns/ontology/> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
@prefix dcterms: <http://purl.org/dc/terms/> .

urpx:Price a owl:Class ;
    rdfs:label "Price"@en ;
    rdfs:comment "Individual pricing component with an amount and applicability rules" .

urpx:chargeType a owl:ObjectProperty ;
    rdfs:label "Charge Type"@en ;
    dcterms:description "Identifies the specific type of charge implementation. Multiple chargeType values can be assigned to a single charge."@en ;
    rdfs:comment "Specific implementation type of a charge"@en ;
    rdfs:domain [ a owl:Class ;
            owl:unionOf ( urpx:Price urpx:PriceDefinition urpx:PriceSet ) ] ;
    rdfs:range urpx:ChargeTypeValue .

JSON-LD​

JSON for Developers, RDF for Machines

JSON-LD is JSON with a semantic layer. Developers work with familiar JSON syntax, while the @context provides RDF semantics: URPX publishes one context at a stable URL, and a document references it rather than declaring its own.

Basic Charge Example:

{
  "@context": [
    "https://urpx.org/ns/context/releases/v0.5.1/jsonld/urpx-context.jsonld",
    { "ex": "https://example.com/" }
  ],
  "@id": "ex:PRC-001",
  "@type": "urpx:Price",
  "urpx:name": "Summer Energy Price",
  "urpx:chargeType": {"@id": "urpx:usageCharge"},
  "urpx:chargeCategory": {"@id": "urpx:auxiliaryCharge"},
  "urpx:unitPrice": "0.12",
  "urpx:priceCurrency": "USD",
  "urpx:hasMetricSpecification": {
    "@type": "urpx:MetricSpecification",
    "urpx:commodity": {"@id": "urpx:electricity"},
    "urpx:measurementKind": {"@id": "urpx:energy"},
    "urpx:unitOfMeasure": {"@id": "urpx:kWh"}
  }
}

Price Set Alternatives with Profile-Alternative References:

This example demonstrates the current URPX pattern in which a PriceSetAlternative links to a reusable ProfileAlternative by IRI:

{
  "@context": [
    "https://urpx.org/ns/context/releases/v0.5.1/jsonld/urpx-context.jsonld",
    { "ex": "https://example.com/" }
  ],
  "@graph": [
    {
      "@id": "ex:condition-expression-zone-h-secondary",
      "@type": "urpx:ConditionExpression",
      "urpx:name": "Zone H secondary voltage",
      "urpx:rootNode": {
        "@id": "ex:condition-zone-h-secondary",
        "@type": "urpx:ComparisonNode",
        "urpx:logicExpression": "service zone and voltage class = ZONE-H-SECONDARY",
        "urpx:operator": {"@id": "urpx:equalsOperator"},
        "urpx:leftOperand": {
          "@type": "urpx:CustomOperandNode",
          "urpx:customConditionProperty": "Service Zone And Voltage Class"
        },
        "urpx:rightOperand": {
          "@type": "urpx:CustomOperandNode",
          "urpx:stringValue": "ZONE-H-SECONDARY"
        }
      }
    },
    {
      "@id": "ex:energy-charge-zone-h-secondary",
      "@type": "urpx:Price",
      "urpx:name": "Zone H Secondary Energy Price",
      "urpx:chargeType": {"@id": "urpx:usageCharge"},
      "urpx:chargeCategory": {"@id": "urpx:auxiliaryCharge"},
      "urpx:unitPrice": "0.09"
    },
    {
      "@id": "ex:demand-charge-zone-h-secondary",
      "@type": "urpx:Price",
      "urpx:name": "Zone H Secondary Demand Price",
      "urpx:chargeType": {"@id": "urpx:demandDirect"},
      "urpx:chargeCategory": {"@id": "urpx:auxiliaryCharge"},
      "urpx:unitPrice": "12.50"
    },
    {
      "@id": "ex:zone-h-secondary",
      "@type": "urpx:ProfileAlternative",
      "urpx:name": "Zone H - Secondary Voltage Alternative",
      "urpx:hasConditionExpression": {
        "@id": "ex:condition-expression-zone-h-secondary"
      }
    },
    {
      "@id": "ex:charges-zone-h-secondary",
      "@type": "urpx:PriceSetAlternative",
      "urpx:referencesProfileAlternative": {"@id": "ex:zone-h-secondary"},
      "urpx:name": "Zone H - Secondary Voltage",
      "urpx:hasPrice": [
        {"@id": "ex:energy-charge-zone-h-secondary"},
        {"@id": "ex:demand-charge-zone-h-secondary"}
      ]
    }
  ]
}

The referencesProfileAlternative property uses an IRI reference (ex:zone-h-secondary) to link the price set alternative to its profile alternative. The ProfileAlternative points to its defining ConditionExpression by IRI instead of embedding the full expression graph inline. This enables:

  • Dereferenceable links for metadata lookup
  • Clean separation between alternative metadata and charges
  • Reusable alternative resources across multiple rate plans
  • Required attachment of hasConditionExpression on the referenced ProfileAlternative

What the @context Does:

  • Maps JSON keys to RDF predicates
  • Defines namespace prefixes
  • Specifies data types
  • Converts JSON to RDF triples automatically

URPX publishes this context at a stable URL, generated from the ontology's own property ranges, so an implementer references it rather than authoring one per document.

Why JSON-LD:

  • Developer Friendly: Looks like regular JSON
  • Tool Support: Excellent library ecosystem
  • Compatibility: Standard JSON tools work
  • Semantic Power: Full RDF capabilities when needed

SHACL (Shapes Constraint Language)​

Data Validation and Quality

SHACL defines shapes that data must conform to. Think of it as "JSON Schema for RDF."

Example SHACL Shape:

@prefix urpx: <https://urpx.org/ns/ontology/> .
@prefix urpx-shacl: <https://urpx.org/ns/shacl/core/> .
@prefix sh: <http://www.w3.org/ns/shacl#> .

urpx-shacl:PriceShape a sh:NodeShape ;
    sh:targetClass urpx:Price ;
    sh:property [
        sh:path urpx:chargeType ;
        sh:node urpx-shacl:ChargeTypeValueShape ;
        sh:minCount 0 ;
    ] .

URPX SHACL Validation:

  • Structural Rules: Required properties, cardinality constraints
  • Data Type Rules: Decimal prices, date formats, string patterns
  • Closed Shapes: Only declared properties and allowed values on each node
  • Relationship Rules: References must point to valid entities

How Validation Works:

  1. Load your URPX data (JSON-LD or Turtle)
  2. Load URPX SHACL shapes
  3. Run SHACL validator
  4. Receive validation report with any errors

Benefits:

  • Automatic Quality Checks: Catch errors before data exchange
  • Clear Error Messages: Know exactly what's wrong and where
  • Specification Enforcement: Ensure conformance to standard
  • Documentation: Shapes document requirements

SPARQL​

Querying Graph Data

SPARQL is the "SQL for RDF" - a query language for semantic data.

Example 1: Find the Named Unit Prices in a Rate Plan

PREFIX urpx: <https://urpx.org/ns/ontology/>

SELECT ?price ?name ?unitPrice
WHERE {
  ?ratePlan urpx:ratePlanUniqueIdentifier "RES-TOU-2025" .
  ?version  urpx:forRatePlan ?ratePlan ;
            urpx:hasPrices/urpx:hasPriceSet/urpx:hasPrice ?price .
  ?price    urpx:name ?name ;
            urpx:unitPrice ?unitPrice .
}

Note the query starts from the version snapshot: versions point at their plan via forRatePlan, so the plan is found by identifier and the versions are found by their link back to it. The query returns prices that carry both a name and a unit price; fixed amounts and price set alternatives need their own patterns.

SPARQL Use Cases:

  • Rate Plan Comparison: Find best rate plans for specific usage patterns
  • Trend Analysis: Track price changes over time
  • Compliance Checking: Verify regulatory requirements
  • Data Discovery: Explore available rate plans

Benefits:

  • Powerful Queries: Navigate complex graph relationships
  • Standardized: Works across any RDF data source
  • Flexible: Can combine data from multiple sources
  • Expressive: Ask questions that are hard to express in SQL

Learning Resources​

RDF & Linked Data​

Official Specifications:

Video Tutorials:

Interactive Tools:

JSON-LD​

Official Resources:

Video Tutorials:

Practical Guides:

Ontologies (OWL)​

Official Specifications:

Video Tutorials:

Tools:

SHACL​

Official Resources:

Video Tutorials:

Interactive Tools:

SPARQL​

Official Resources:

Video Tutorials:

Reference Materials:

Query Endpoints:

Knowledge Graphs​

General Resources:

Industry Applications:

Books​

For Beginners:

  • "Learning SPARQL" by Bob DuCharme - Practical query guide
  • "Semantic Web for the Working Ontologist" by Dean Allemang & James Hendler - Industry standard

For Advanced Users:

  • "Validating RDF Data" by Jose Labra Gayo et al. - SHACL deep dive
  • "Linked Data: Evolving the Web into a Global Data Space" by Tom Heath & Christian Bizer

Communities​

Discussion Forums:

Conferences:

Next Steps​

For Working Group Members​

  1. Start Simple: Review the RDF Primer and try the JSON-LD Playground
  2. Hands-On Practice: Work through URPX examples in the Tutorial
  3. Ask Questions: Use GitHub Discussions in urpx-org repositories
  4. Contribute: Test with real rate plan data and provide feedback

Deeper Learning Path​

Week 1-2: Foundations

  • Watch introductory videos on RDF and Linked Data
  • Experiment with JSON-LD Playground
  • Read W3C RDF Primer

Week 3-4: URPX Specifics

  • Study URPX ontology structure
  • Work through tutorial examples
  • Try SHACL validation on sample data

Week 5-6: Querying

  • Learn SPARQL basics
  • Practice queries on URPX data
  • Explore DBpedia for broader context

Week 7-8: Advanced Topics

  • Review ontology design patterns
  • Understand SHACL advanced features
  • Contribute to URPX development