Semantic Web Explained: From Data to Meaning with RDF and Linked Data

We live in a world filled with data.

Books are described in digital catalogs. People publish information on websites. Research papers reference other publications. Online stores maintain product catalogs, while applications exchange information through APIs.

Yet, having access to data does not necessarily mean that different applications can understand or integrate it correctly.

Consider two systems that describe a book:

{
  "title": "Introduction to Knowledge Graphs",
  "author": "Jane Doe",
  "publisher": "Example Press"
}

Another system might represent the exact same information differently:

{
  "book_name": "Introduction to Knowledge Graphs",
  "creator": "Jane Doe",
  "publisher_name": "Example Press"
}

Both records are perfectly understandable to a person. We can readily recognize that title and book_name refer to similar concepts, just as author and creator appear to describe related roles.

But what happens when these records must be combined automatically?

A computer cannot always assume that two differently named fields have exactly the same meaning. Even when field names are identical, their definitions, value formats, and intended relationships may differ substantially.

This is one of the core problems addressed by the Semantic Web.

The Semantic Web builds on standard Web technologies and formal data representation to make information more suitable for integration, interpretation, and reuse by applications. Instead of relying exclusively on the structure of individual documents, it provides ways to identify resources, describe their relationships, and connect them through shared vocabularies.

At the center of this approach are several important standards, including the Resource Description Framework (RDF), Linked Data, and query languages such as SPARQL.

In this article, we explore these ideas from the ground up: starting with an ordinary data record, transforming it into a semantic representation, and examining how that representation makes relationships explicit, interoperable, and queryable.

---

1. The Problem: Data Is Not the Same as Shared Meaning

Let’s begin with a simple scenario. Suppose two online bookstores publish information about a particular book.

The first bookstore stores:

Field	Value
title	Introduction to Knowledge Graphs
author	Jane Doe
publisher	Example Press

The second bookstore uses:

Field	Value
book_name	Introduction to Knowledge Graphs
creator	Jane Doe
publisher_name	Example Press

To a human, the relationship between these fields seems obvious. However, an application integrating the two catalogs must programmatically determine whether the fields represent equivalent concepts.

A developer could write custom mapping rules:

field_mapping = {
    "book_name": "title",
    "creator": "author",
    "publisher_name": "publisher",
}

For a small application with two sources, this may be entirely reasonable.

The difficulty quickly escalates when the number of sources, data models, and relationships increases:

• One system might use creator to refer strictly to an individual author. Another might use it for a person, an organization, an editor, or another entity responsible for producing a resource.
• Even more importantly, a person’s name is not necessarily a unique identifier. Two different authors can easily share the same name.

Consequently, integration involves far more than matching columns or comparing text strings. It requires understanding the entities being described and the relationships among them.

This challenge can be examined through three related questions:

1. What does the data represent?
   A value such as "Jane Doe" might refer to an author, a customer, an editor, or another individual entirely.
2. How are the concepts related?
   A book can have an author, a publisher, a subject, and a publication date. These relationships carry distinct semantics.
3. How can different sources express compatible meanings?
   One source might use its own internal ID for an author, while another uses an external identifier for the same person. The integration process needs a reliable way to connect those descriptions.

The Semantic Web provides a set of principles and technologies to address these questions. It does not eliminate the need for data modeling or guarantee that every application will automatically understand every dataset. Rather, it provides a formal foundation on which meaningful, machine-processable relationships can be represented and shared.

---

2. What Is the Semantic Web?

The term Semantic Web is commonly associated with Tim Berners-Lee’s vision of extending the Web so that information can be described in ways that support greater machine processing and interoperability.

The word semantic refers to meaning.

In this context, the goal is to make the meaning of data more explicit through structured descriptions, identifiable resources, and defined relationships.

Traditional Web technologies allow us to create documents, link pages via hyperlinks, and exchange information. The Semantic Web builds directly on this infrastructure by enabling links between the things being described, rather than limiting links to documents alone.

For example, a website might state:

Jane Doe wrote Introduction to Knowledge Graphs.

A human reader understands that relationship immediately. A semantic representation expresses that exact statement in a structured graph form:

In this model, the connection is not merely a visual line or a sentence inside a paragraph. It represents a named relationship between two identified resources.

Such a representation can be queried, combined with other datasets, and processed by compatible software across organizational boundaries.

2.1. Does the Semantic Web mean that machines understand everything?

No. This is an important distinction to maintain.

Semantic Web technologies make data structures and relationships explicit, giving software a formal basis for processing information. They do not automatically provide human-level comprehension, common sense, or a complete understanding of natural language.

A computer can process the statement:

ex:book1 schema:author ex:janeDoe .

provided it has access to the graph and the relevant vocabulary.

However, this does not, by itself, enable the computer to understand the literary quality of the book, determine whether the author is trustworthy, or infer an opinion about the publication. Such conclusions require additional domain models, data, reasoning capabilities, or machine learning algorithms.

The Semantic Web should therefore be understood as an approach to structuring and connecting meaning, not as a mechanism that magically makes every machine intelligent.

2.2. Is the Semantic Web the same as the World Wide Web?

They are related, but they are not identical.

• The World Wide Web provides a global information space in which documents and resources can be accessed and linked.
• The Semantic Web builds on that Web infrastructure to represent information and relationships in a form that supports machine processing and data interoperability.

The technologies overlap, but they emphasize different aspects:

• A conventional website can be entirely functional and valuable without publishing RDF.
• A dataset can use RDF without being openly accessible to the public internet.
• And a Linked Data publisher can make semantic descriptions available to other applications through standard Web identifiers.

---

3. From Data to Semantic Representation

To understand how the Semantic Web operates in practice, let’s trace a concrete example throughout this guide.

Imagine we are building a digital book catalog containing three entities:

1. A book titled Introduction to Knowledge Graphs.
2. An author named Jane Doe.
3. A publisher named Example Press.

A conventional JSON representation might look like this:

{
  "id": "book-1",
  "title": "Introduction to Knowledge Graphs",
  "author": "Jane Doe",
  "publisher": "Example Press"
}

This format works well for many applications. JSON is universally supported across modern APIs and programming languages.

However, notice that the author and publisher are represented only as primitive strings:

• If another catalog contains an author named "Jane Doe", how do we verify whether it refers to the same person?
• What if the publisher changes its business name?
• What if another system describes the author using a different property key?

The JSON record alone does not resolve these ambiguities. An application could solve them using custom identifiers, metadata endpoints, and translation layers, but those mechanisms would have to be manually reinvented for every integration.

The Semantic Web offers a standardized foundation for representing such relationships. Rather than treating every value as an isolated field, we model the book, author, and publisher as resources and describe how they relate to one another.

---

4. Understanding RDF: The Foundation of Semantic Data

The Resource Description Framework (RDF) is a W3C standard model for representing information on the Web.

RDF expresses all data through statements called triples. Each triple consists of three components:

$$\text{Subject} \longrightarrow \text{Predicate} \longrightarrow \text{Object}$$

Consider the statement:

$$\text{Introduction to Knowledge Graphs} \xrightarrow{\text{has author}} \text{Jane Doe}$$

Component	Value	Meaning
Subject	Introduction to Knowledge Graphs	The resource being described
Predicate	has author	The relationship connecting them
Object	Jane Doe	The related resource or value

Abstractly, the statement can be written as:

(Book, hasAuthor, Author)

This representation makes the relationship explicit and machine-processable.

4.1. From Triples to Graphs

An RDF graph is formed naturally from a collection of triples. For our catalog example, the graph connects the book to its author, publisher, and descriptive values:

In this graph:

• Nodes represent entities or literal values.
• Directed edges represent named relationships (predicates).

RDF provides a graph-based model that can represent interconnected information without requiring every source to adhere to the exact same tabular schema. As noted in the W3C RDF Overview, RDF is an open standard that supports merging data across differing, heterogeneous schemas.

4.2. Why Use Triples?

Triples provide an atomic, composable representation:

• Each statement describes exactly one relationship.
• Multiple statements can be combined seamlessly into a larger graph.
• New statements can extend the graph without requiring migrations or restructuring existing records.

Suppose another dataset introduces information about the author’s research interests:

$$\text{janeDoe} \xrightarrow{\text{interestedIn}} \text{Knowledge Representation}$$

We can add that triple directly into the existing graph. The original book description requires zero modifications. This flexibility is a primary reason RDF is so effective for data integration and knowledge management.

4.3. Can the Object Always Be Text?

No. The object of an RDF triple can be either another resource or a literal value:

book1 ──► author ──► janeDoe          (Object is an identified resource)
book1 ──► title  ──► "Introduction..." (Object is a literal value)

This distinction is fundamental: RDF models both relationships between entities and concrete attribute values associated with those entities.

---

5. Understanding IRIs, Literals, and Blank Nodes

RDF statements rely on three primary kinds of terms: IRIs, literals, and blank nodes.

5.1. IRIs: Identifying Resources

An IRI (Internationalized Resource Identifier) provides a global identifier for a resource:

https://example.org/book1
https://example.org/janeDoe
https://example.org/examplePress

These identifiers unambiguously distinguish the book, the author, and the publisher.

Why is this powerful? If two independent catalogs reference the string "Jane Doe", we cannot determine whether they mean the same individual. But if both intentionally point to https://example.org/janeDoe, their data connects automatically:

catalogA:book1 ── schema:author ──► https://example.org/janeDoe
catalogB:book9 ── schema:author ──► https://example.org/janeDoe

An IRI is not absolute proof of universal real-world uniqueness—its reliability depends on how the publisher manages identifier policies. Nonetheless, well-managed IRIs make distributed data integration predictable. In RDF 1.1, IRIs build upon URI standards while supporting internationalized character sets.

5.2. Literals: Representing Values

A literal represents concrete data values such as strings, numbers, or dates:

"Jane Doe"
"Introduction to Knowledge Graphs"
42
"2024-01-01"^^<http://www.w3.org/2001/XMLSchema#date>

Literals can also declare explicit language tags:

"Knowledge Graphs"@en
"Graf Pengetahuan"@id

Language tags allow applications to handle localized labels cleanly. Datatypes (such as XML Schema types xsd:date, xsd:integer) ensure that software does not confuse a text string "42" with a numeric value 42.

5.3. Blank Nodes: Resources Without Explicit Global Identifiers

RDF also supports blank nodes. A blank node represents a resource that does not require an externally visible global IRI.

For example, if an author’s postal address is modeled as a compound structure (street, city, postal code), and that address does not need an independent global identifier, it can be represented via a blank node.

However, blank nodes are locally scoped to a particular file or graph. Applications cannot assume that blank nodes in separate graphs refer to the same resource.

---

6. Writing RDF with Turtle

RDF is an abstract data model, not a single file format. It can be serialized into several formats, with Turtle (Terse RDF Triple Language) being one of the most readable and compact.

Here is our book catalog represented completely in Turtle:

@prefix ex: <https://example.org/> .
@prefix schema: <https://schema.org/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

ex:book1 a schema:Book ;
    schema:name "Introduction to Knowledge Graphs"@en ;
    schema:author ex:janeDoe ;
    schema:publisher ex:examplePress ;
    schema:datePublished "2024-01-01"^^xsd:date .

ex:janeDoe a schema:Person ;
    schema:name "Jane Doe" .

ex:examplePress a schema:Organization ;
    schema:name "Example Press" .

This snippet uses the popular Schema.org vocabulary alongside our custom domain prefix ex:. Let’s break down the syntax:

6.1. Prefix Declarations

@prefix ex: <https://example.org/> .
@prefix schema: <https://schema.org/> .

Prefixes provide shorthands for full IRIs. Instead of writing <https://example.org/book1>, we write ex:book1. Similarly, schema:Book expands to <https://schema.org/Book>.

6.2. The a Keyword

ex:book1 a schema:Book .

The keyword a is Turtle shorthand for the predicate rdf:type. This assertion explicitly tells systems that ex:book1 is an instance of the class schema:Book.

6.3. Semicolons and Periods

Turtle uses punctuation to keep triples concise:

• A semicolon (;) separates multiple predicate-object pairs that share the same subject.
• A period (.) marks the termination of a statement sequence.

The block above is functionally identical to writing individual triples repeatedly, but with significantly higher readability.

6.4. What Does the Graph Express?

Our graph explicitly states:

• ex:book1 is a schema:Book.
• Its English title is "Introduction to Knowledge Graphs".
• Its author is the resource ex:janeDoe, which is defined as a schema:Person named "Jane Doe".
• Its publisher is ex:examplePress, defined as a schema:Organization named "Example Press".
• Its publication date is typed as an xsd:date.

Notice how schema:name points to a literal, whereas schema:author points to an identified resource. This allows independent statements to describe ex:janeDoe without cluttering the book’s record.

---

7. Why Vocabulary Reuse Matters

Anyone can create arbitrary prefixes and properties:

# Custom proprietary predicate
ex:book1 ex:writer ex:janeDoe .

# Standardized Schema.org predicate
ex:book1 schema:author ex:janeDoe .

While a human might guess that ex:writer and schema:author mean the same thing, software cannot safely make that leap.

Reusing established vocabularies reduces ambiguity and immediately facilitates interoperability across the global Web:

• Schema.org: Widely supported for entities such as books, people, articles, organizations, and events.
• Dublin Core (dc / dcterms): Standardized metadata terms for library and information resources (dc:title, dc:creator).
• SKOS (Simple Knowledge Organization System): Designed for classification schemes, taxonomies, and thesauri.

Vocabulary reuse does not magically solve every modeling challenge—two systems can still interpret property constraints differently—but it provides a shared baseline that drastically lowers integration friction.

---

8. RDF Is a Data Model, Not a File Format

It is vital to separate the data model from its serialization formats:

Format	Characteristics	Typical Use Case
Turtle (.ttl)	Human-readable, compact, prefix-based	Documentation, configuration, manual authoring
JSON-LD (.jsonld)	Standard JSON structure with semantic @context	Web applications, REST APIs, SEO metadata
N-Triples (.nt)	One triple per line, plain text without abbreviations	Bulk data processing, high-throughput parsing
RDF/XML (.rdf)	XML-based serialization	Legacy enterprise systems, older W3C toolchains
N-Quads (.nq)	Line-based triples with an optional fourth graph IRI	Managing named graphs and multi-dataset stores

To see how the same data model serializes into JSON-LD, look at this equivalent snippet:

{
  "@context": {
    "schema": "https://schema.org/",
    "name": "schema:name",
    "author": {
      "@id": "schema:author",
      "@type": "@id"
    },
    "publisher": {
      "@id": "schema:publisher",
      "@type": "@id"
    }
  },
  "@id": "https://example.org/book1",
  "@type": "schema:Book",
  "name": "Introduction to Knowledge Graphs",
  "author": "https://example.org/janeDoe",
  "publisher": "https://example.org/examplePress"
}

In JSON-LD, @context maps normal JSON keys to semantic IRIs, while @type: "@id" tells the parser that the string value is an identified resource IRI, not a plain text literal. Modern web applications can consume this directly with standard JSON parsers while retaining full RDF semantics. For more details, consult the W3C RDF 1.1 Primer.

---

9. What Makes Data Linked?

Having data in RDF does not automatically mean it qualifies as Linked Data.

Linked Data describes the methodology for publishing and connecting structured data on the Web so that both humans and machines can discover resources and traverse relationships across independent databases.

The W3C Linked Data Principles outline four core guidelines formulated by Tim Berners-Lee:

1. Use URIs as names for things.
2. Use HTTP URIs so that people and systems can look them up.
3. When someone looks up a URI, provide useful information using open standards (such as RDF and SPARQL).
4. Include links to other URIs so that consumers can discover further related things.

9.1. Distinguishing Resources via Persistent Identifiers

If our local bookstore catalog identifies an author as:

https://example.org/janeDoe

and an academic research repository identifies the same person as:

https://research.example.net/person/742

We should not merge them based purely on a name match. However, if the publishers establish an explicit link:

<https://example.org/janeDoe> owl:sameAs <https://research.example.net/person/742> .

Applications can now traverse between both systems with confidence, aggregating the author’s books from one source and academic papers from the other.

9.2. Linked Data Is More Than Putting URLs in a Spreadsheet

Consider an ordinary spreadsheet column containing a URL:

Book	Author URL
Introduction to Knowledge Graphs	https://example.org/janeDoe

A URL alone does not make a dataset Linked Data. Linked Data requires that looking up that URL (dereferencing it over HTTP) yields structured metadata, that the identifier remains persistent, and that the returned representation links outward to other resources in the wider data web.

---

10. From Separate Records to an Interconnected Knowledge Graph

When datasets interconnect through shared identifiers and consistent vocabularies, they coalesce into a Knowledge Graph:

A knowledge graph represents entities and their relationships as an interconnected graph structure. While RDF is a premier standard for modeling knowledge graphs, not all knowledge graphs are strictly RDF-based (some use labeled property graphs such as Neo4j). However, RDF offers a globally interoperable standard that is uniquely suited for cross-organization data exchange without centralized coordination.

---

11. Querying RDF with SPARQL

To retrieve and manipulate data in an RDF graph, the W3C defined SPARQL (SPARQL Protocol and RDF Query Language).

SPARQL functions for graph data similarly to how SQL functions for relational databases. Instead of joining relational tables, SPARQL matches graph patterns.

Suppose we want to find all books, along with their author names and publisher names. We write:

PREFIX ex: <https://example.org/>
PREFIX schema: <https://schema.org/>

SELECT ?title ?authorName ?publisherName
WHERE {
  ?book a schema:Book ;
        schema:name ?title ;
        schema:author ?author ;
        schema:publisher ?publisher .

  ?author schema:name ?authorName .
  ?publisher schema:name ?publisherName .
}

Let’s dissect the components:

• PREFIX: Defines namespaces to shorten IRIs.
• ?book, ?title, ?authorName: Variables denoted by a leading ?.
• WHERE { ... }: The graph pattern that the SPARQL engine attempts to match against the RDF triples.
• SELECT: Specifies which variable bindings to return in the tabular output.

The query engine evaluates the graph patterns and returns a clean result table:

?title	?authorName	?publisherName
Introduction to Knowledge Graphs	Jane Doe	Example Press

Because the data is modeled as an interconnected graph, we did not have to write manual database joins or coordinate distinct API endpoints. The W3C SPARQL 1.1 Specification provides detailed documentation on advanced patterns, filters, and aggregations.

---

12. How Does an Ontology Add More Meaning?

RDF gives us the graph model. But what if we want to declare logical rules, constraints, and class hierarchies? That is the role of Ontologies.

An ontology defines formal descriptions of concepts within a domain and specifies the relationships and constraints holding between them. Languages like RDFS (RDF Schema) and OWL (Web Ontology Language) provide the formal constructs to express these axioms.

12.1. Class Hierarchies and Subclasses

Suppose our ontology establishes that every Book is a type of CreativeWork:

@prefix schema: <https://schema.org/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix ex: <https://example.org/> .

# Ontology rule
schema:Book rdfs:subClassOf schema:CreativeWork .

# Instance assertion
ex:book1 a schema:Book .

Under an RDFS reasoner, the system can automatically infer:

ex:book1 a schema:CreativeWork .

We did not need to manually assert that ex:book1 is a CreativeWork. The inference emerges logically from the ontology axiom and the instance type.

12.2. What Reasoning Does (and Does Not) Do

Reasoning is the mechanical deduction of new facts from existing assertions and formal logical rules.

However, reasoning does not verify real-world factual truth:

• If a dataset asserts that an author wrote a book, a reasoner processes that assertion according to the model rules.
• It cannot independently determine whether the statement is historically accurate or fabricated.

Ontologies formalize structure and deduction; they do not replace data quality validation and trustworthy sourcing.

---

13. Semantic Web Technologies: How the Pieces Fit Together

The Semantic Web stack comprises several complementary standards, each addressing a specific layer of the data lifecycle:

Technology	Primary Role
RDF	Graph data model representing information as triples
Turtle	Compact, human-readable serialization syntax for RDF
JSON-LD	JSON-based serialization designed for Linked Data and web APIs
Linked Data	Best practices for publishing and connecting web-accessible data
SPARQL	Standardized declarative query language for RDF graphs
RDFS	Basic vocabulary for declaring classes, properties, and hierarchies
OWL	Expressive ontology language supporting advanced logical reasoning
SHACL	Shape-based validation language for declaring data integrity constraints

These tools are modular: you do not need OWL or SHACL to benefit from RDF. A simple application can use RDF and Turtle solely for clean data interchange, adopting ontologies and shape validation only when complexity demands them.

---

14. A Practical Application: Integrating Two Book Catalogs

Let’s return to our opening scenario: combining two independently maintained bookstore catalogs.

• Catalog A:

  { "id": "book-1", "title": "Introduction to Knowledge Graphs", "author": "Jane Doe" }

• Catalog B:

  { "record": "BK-742", "book_name": "Introduction to Knowledge Graphs", "creator_id": "person-19" }

A standard semantic integration workflow follows six clear steps:

1. Establish Resource Identifiers: Formulate an IRI scheme for books, authors, and publishers.
2. Define the Semantic Target Model: Select shared vocabularies (e.g., schema:Book, schema:author).
3. Map Source Schemas: Translate Catalog A’s title and Catalog B’s book_name to schema:name.
4. Generate RDF Triples: Export or ingest the records as RDF graphs.
5. Resolve Entity Identity: Verify whether author: "Jane Doe" and creator_id: "person-19" refer to the same human, and declare links (owl:sameAs or shared IRI) accordingly.
6. Query the Integrated Graph with SPARQL: Applications now execute queries across the combined catalog seamlessly.

---

15. Semantic Web and Traditional Data Integration

Should RDF and Linked Data replace relational databases (PostgreSQL, MySQL), document stores, or JSON APIs?

No. Each technology excels in distinct engineering scenarios:

• Relational Databases: Unmatched for transactional operations (ACID), high-speed indexing, and strict tabular records.
• JSON REST APIs: Ideal for standard request-response communication between microservices and frontend clients.
• RDF & Linked Data: Ideal for integrating heterogeneous data across organizational boundaries, evolving schemas without breaking existing consumers, and cross-domain querying.

In production architectures, they commonly coexist: relational databases handle transactional storage, while an export pipeline projects entities into an RDF knowledge graph for analysis, discovery, and federation.

---

16. Common Misconceptions About the Semantic Web

1. “The Semantic Web is just pretty graph visualizations.”
   Visual graph diagrams are merely visual representations. The real power lies in formal semantics, persistent IRIs, and standardized query mechanics.
2. “RDF is just another file format.”
   RDF is an abstract graph data model. Formats like Turtle, JSON-LD, and N-Triples are serializations of that model.
3. “Identical names mean identical entities.”
   Names are strings; entities are resources. Two distinct authors named Jane Doe must have separate IRIs.
4. “RDF automatically fixes data quality.”
   If input data contains bad records, the RDF graph will contain well-structured bad records. Modeling rigor and validation remain essential.
5. “Linked Data must always be public and open.”
   Linked Data principles apply equally inside private enterprise intranets and secured data platforms.

---

17. When Should You Use Semantic Web Technologies?

Semantic Web technologies shine when problems exhibit high interconnectedness, schema heterogeneity, or multi-source integration requirements:

• Digital Libraries and Academic Archives: Linking authors, citations, papers, and institutions.
• Enterprise Knowledge Management: Connecting internal documentation, code repositories, teams, and product components.
• Biomedical & Life Sciences: Integrating genomic data, clinical trials, chemical compounds, and medical ontologies.
• Context for AI and LLM Systems: Providing structured, verified domain context to enhance Retrieval-Augmented Generation (RAG) and reasoning pipelines.

---

18. Limitations and Engineering Considerations

Adopting semantic technologies comes with real trade-offs:

• Modeling Complexity: Designing robust ontologies and selecting suitable vocabularies requires domain expertise.
• Entity Resolution Overhead: Establishing reliable identity mappings across noisy datasets demands careful deduplication.
• Reasoning Costs: Highly expressive OWL ontologies can be computationally expensive to compute at scale.
• Identifier Governance: Maintaining persistent IRIs over decades requires long-term organizational discipline.

---

19. A Recommended Learning Path

To build practical mastery without being overwhelmed by standard specifications, take a gradual, project-oriented approach:

1. Master RDF & Turtle: Practice hand-crafting small graphs, declaring prefixes, and writing clean triples.
2. Learn SPARQL: Query local graphs, filter values, and use pattern matching.
3. Explore Vocabularies: Study Schema.org, Dublin Core, and SKOS.
4. Hands-on Python with RDFLib: Use the open-source RDFLib library to parse, serialize, and query RDF programmatically:

   from rdflib import Graph, URIRef, Literal, Namespace
   from rdflib.namespace import RDF, FOAF
   
   g = Graph()
   jane = URIRef("https://example.org/janeDoe")
   g.add((jane, RDF.type, FOAF.Person))
   g.add((jane, FOAF.name, Literal("Jane Doe")))
   
   print(g.serialize(format="turtle"))

5. Data Validation with SHACL: Write data shapes to ensure graph integrity before deploying to production.

---

Conclusion

The fundamental problem of data exchange is not a lack of data, but a lack of shared, machine-actionable meaning.

By moving from isolated strings and proprietary tables to globally identified resources, standardized vocabularies, and interconnected graph triples, the Semantic Web provides a resilient architecture for data interoperability.

The journey from raw data to actionable meaning begins when we stop treating values as isolated fields and start explicitly modeling the entities they represent and the relationships that bind them together.

---

References and Further Reading

• W3C — RDF: Resource Description Framework Overview
• W3C — RDF 1.1 Primer
• W3C — RDF 1.1 Concepts and Abstract Syntax
• W3C — Linked Data Principles
• W3C — SPARQL 1.1 Query Language
• W3C — JSON-LD 1.1 Specification
• W3C — OWL 2 Web Ontology Language Overview
• Schema.org — Open Community Vocabularies
• RDFLib — Python Library for RDF and Linked Data