Can Two Teams Describe the Same Resource?

One supplier calls a pump P7. Another uses P7 for a spare motor. Meanwhile, two teams describe the same supply under different display names. Botie cannot combine these records safely by comparing their text labels.

We need identifiers whose meaning survives the move between datasets, and a shared way to state a relationship. RDF expresses a statement using a subject, a predicate and an object. SPARQL asks which assignments to variables make patterns of those statements match.

The same identifier text occurs as a resource and as a literal.

In the statement P7 dependsOn S1, the subject is P7, the predicate is dependsOn and the object is S1. RDF identifies predicates with IRIs too, so two independently invented properties with the same short name need not mean the same thing.

A resource IRI is an identifier, not a promise that fetching its URL will return a useful page. Choose and document identifiers that remain stable when a display name changes.

The full identifier, rather than the label drawn beside a node, controls matching.

A resource object can participate in more statements. A literal is a value, such as a name, a date or a number. A literal whose characters look like an IRI is still a literal. Datatype and language tags carry meaning that a plain string comparison can lose.

Our compact Python fixture uses kind to distinguish IRI objects from literals. It deliberately omits blank nodes and datatype processing. Blank nodes represent resources without a global IRI; their local labels are not durable cross-file business keys.

The workshop projects only resource-to-resource statements. It is not a general RDF parser.

objects=[{'kind':'iri','value':'https://perceptronlab.example/S1'},{'kind':'literal','value':'https://perceptronlab.example/S1'}]
print([o['kind'] for o in objects])

['iri', 'literal']

In SPARQL, ?asset names a variable. A triple pattern with that variable as subject asks which resources have the stated predicate and object. PREFIX only abbreviates IRIs in the query text; SELECT chooses the variables returned.

The braces contain the graph pattern. Several patterns sharing ?asset must agree on the same resource binding. FILTER can constrain a bound value, while OPTIONAL adds bindings when a pattern exists without requiring it for every row.

The same variable-binding idea from Cypher appears in a different graph data model.

PREFIX ex: <https://perceptronlab.example/>
SELECT DISTINCT ?asset
WHERE { ?asset ex:dependsOn ex:S1 . }
ORDER BY ?asset

An RDF graph is a set of triples, so repeating an identical triple does not add another graph statement. A query can still produce repeated projected bindings through several matching combinations. DISTINCT applies to the projected query result, not to an imagined duplicate edge identity.

In a property graph, two separately identified relationships can have the same endpoints and type. That difference matters when importing visit events. Do not mechanically convert each event into an identical RDF triple and expect its identity to survive.

Model an event as an identified resource when the event itself needs its own properties or evidence.

If the dataset has no dependsOn statement for P9, we know that this dataset did not produce a match. We have not proved that P9 has no physical dependency. RDF’s open-world interpretation leaves room for information that has not been recorded.

Inference is also an explicit choice. A SPARQL store does not necessarily apply every ontology rule automatically. Know the configured entailment regime before interpreting a query that relies on inferred types or relationships.

State whether the report concerns recorded statements, inferred statements or a verified complete inventory.

A short RDF triple does not by itself say who asserted it or which source document supported it. Named graphs and explicit provenance models can retain source context, but their interpretation must be documented.

Our next lesson keeps claims separate from the sources that support them. That gives Botie somewhere to look when the two teams disagree instead of silently treating the latest import as the truth.

Interoperable syntax makes disagreement easier to represent; it does not resolve it.