Ontology 101 : URIs Are Not Just URLs: The Identity Crisis at the Heart of the Web

The Identifier Problem

In Previous Article we established that every entity in a knowledge graph needs a globally unique identifier — a URI. But what exactly is a URI? How does it differ from the URLs you type into a browser every day? And how do you design identifiers that will remain stable and meaningful for decades?

These questions might seem like plumbing. They are not. Getting your identifier strategy wrong is one of the most expensive mistakes you can make in a knowledge graph project. Changing a URI after data is published is equivalent to renaming every primary key in a production database — every foreign reference breaks.

The Terminology Minefield

Let’s clear up the terminology once and for all.

The key insight: every URL is a URI, but not every URI is a URL.

In the Semantic Web, we almost always use HTTP URIs because they satisfy Linked Data rule #2: they are resolvable over the standard web protocol. When a machine encounters an HTTP URI it does not recognize, it can dereference it (make an HTTP GET request) and receive structured data in return.

https://building.example/sensor/TMP-B3-R12-01
      ↑                  ↑
  HTTP scheme      path identifying the specific resource

The Two URI Design Patterns

When you want a URI to both identify a thing and return data when looked up, you face a design decision. There are two widely-used patterns.

Pattern 1: Hash URIs (#)

The resource is identified by appending a fragment (#identifier) to a document URI. When dereferenced, the server returns the whole document and the client reads the fragment.

# The ontology document URI
<https://building.example/ontology>

# Individual entity URIs (hash-based)
<https://building.example/ontology#Chiller>
<https://building.example/ontology#VAV_Box>
<https://building.example/ontology#Server_Room_B>

Pros: Simple — one document serves all entities. Works well for small, stable vocabularies. Cons: The entire document must be downloaded to resolve any single URI. Fragments are stripped by HTTP — you cannot serve different content for different entities without extra server logic.

Best for: Ontology class and property definitions (e.g. FOAF uses hash URIs: foaf:Person expands to [http://xmlns.com/foaf/0.1/Person)](http://xmlns.com/foaf/0.1/Person))

Pattern 2: Slash URIs (/)

Each entity gets its own distinct path. The server can serve a separate response for each resource.

# Entity URIs (slash-based)
<https://building.example/equipment/chiller/RKP-007>
<https://building.example/space/room/B3-R12>
<https://building.example/sensor/TMP-B3-R12-01>

Pros: Each URI is independently dereferenceable. The server can return different RDF representations for different entities. Scales to millions of instances. Cons: Requires server-side routing (or a 303 redirect pattern — see below).

Best for: Instance data — individual sensors, rooms, assets, people.

The 303 Redirect Pattern

Here is the subtle problem with using HTTP URIs to identify things (not just web pages): HTTP was designed to retrieve representations of resources, not to identify physical objects.

If https://building.example/chiller/RKP-007 is a URI for a physical chiller, what should happen when a browser requests it? Returning HTML about the chiller would be useful for humans but confusing for machines expecting RDF.

The W3C’s solution is the 303 See Other redirect:

1. Client: GET https://building.example/chiller/SE-007
           Accept: text/turtle

2. Server: 303 See Other
           Location: https://building.example/data/chiller/RKP-007.ttl
3. Client: GET https://building.example/data/chiller/RKP-007.ttl
4. Server: 200 OK  (returns RDF Turtle)

The original URI (/chiller/RKP-007) is the identity URI — it names the real-world thing. The redirect target (/data/chiller/RKP-007.ttl) is the information URI — it locates the document about that thing. This preserves the principle that the identity URI refers to the chiller itself, not a webpage.

Designing Stable Identifiers for Your Smart Building

Here are practical rules for minting URIs that will not haunt you:

Rule 1 — Use a domain you control

Never use a third-party domain like github.io as your canonical identifier base if there is any chance you might move. Register a dedicated domain and protect it.

✅ https://ontology.yourcompany.com/building/
❌ https://ravipeta.github.io/ontology/building/  (personal page — may disappear)

Rule 2 — Separate the version from the identifier

Put the version in the ontology metadata, not in the URI path. Stable identifiers should survive version upgrades.

# ✅ Good — version is metadata, not part of the identity URI
<https://onto.example/building/Chiller>
    owl:versionInfo "2.1.0" .

# ❌ Bad - breaking change when v3 arrives
<https://onto.example/building/v2/Chiller>

Rule 3 — Use a consistent, readable path structure

/ontology/{domain}/{ConceptName}     →  for classes and properties
/data/{domain}/{type}/{local-id}     →  for instances

Applied to our Smart Building:

# Classes
<https://onto.example/building/ontology/Chiller>
<https://onto.example/building/ontology/TemperatureSensor>
<https://onto.example/building/ontology/VAV_Box>

# Instances
<https://onto.example/building/data/chiller/RKP-007>
<https://onto.example/building/data/sensor/TMP-B3-R12-01>
<https://onto.example/building/data/floor/14>

Rule 4 — Never encode transient information in a URI

❌ https://onto.example/building/active/chiller/RKP-007   (status changes)
❌ https://onto.example/building/floor14/room12/sensor01  (might move floors)
✅ https://onto.example/building/data/sensor/TMP-B3-R12-01  (stable unique ID)

Rule 5 — Document your URI policy

Publish a short policy page at your base URI explaining the structure, redirect behavior, and deprecation process. Future maintainers (including future you) will thank you.

IRIs: Unicode in Identifiers

Standard URIs are limited to ASCII characters. For organizations whose domain names, asset codes, or location names include non-ASCII characters, the W3C extended the specification with IRIs (Internationalized Resource Identifiers).

# A valid IRI — contains Japanese characters
<https://onto.example/建物/センサー/001>

# Turtle handles IRIs natively
@prefix 建物: <https://onto.example/建物/> .
建物:センサー/001  a  建物:温度センサー .

Most modern triple stores and RDF libraries handle IRIs correctly. If you need to embed IRIs in legacy XML-based systems, percent-encode the non-ASCII portions.

Reusing vs Minting: A Practical Decision Tree

Before minting a new URI, always check whether a suitable one already exists:

For our Smart Building, the shortlist of existing URIs to reuse before minting new ones:

Key Takeaways

• URI is the general concept; URL is a URI that locates a resource; IRI extends URI with Unicode
• Use hash URIs for small stable ontology definitions; slash URIs for large instance datasets
• The 303 redirect pattern separates the identity of a thing from the document describing it
• Stable URI design: own your domain, version in metadata, never encode transient state
• Always check existing open ontologies before minting a new URI

What’s Next

Now that every entity has a stable identity URI, Next Article examines the data structure that connects them: the graph. We will cover directed vs undirected graphs, why graph traversal beats recursive SQL JOINs for connected data, and how to visually reason about a knowledge graph before writing a single line of code.