例如：
entity:f06574 rdfs:label "Orioles"
或这样的格式：
:tt0268252 a :Movie .
[无论哪种情况，f06574和tt0268252都是代码，不是实体或实例的实际字符串。一个原因可能是由于相同的字符串可能引用了不同的事物，但是在RDF世界中，某事物的标识符始终以其唯一的URI作为前缀，因此即使使用了字符串，也不会造成歧义。可读且不透明的代码。
这种表示的真正原因是什么？ Freebase中的三元组相似。
这类似于关系数据库理论中的surrogate keys。代理密钥不是从应用程序数据派生的，因此不具有语义。这与从应用程序数据派生的自然键相反。
代理键的主要优点是，如果应用程序数据发生更改，则不需要更改对数据的引用。对于自然键，如果应用程序数据发生更改，它将导致对数据的引用发生更改。因此，所有外键都需要相应地更新。
在语义网中，如果我们本质上希望标签从说tt0268252变为Movie，则不需要更新任何引用Film的三元组。如果我们使用http://awesome/movie之类的字符串并且需要将其更改为电影，我们将需要更改IRI http://awesome/film，这将违反语义网的原理（IRI不应更改）。否则我们将不得不与http://awesome/movie一起使用http://awesome/movie rdfs:label "Film"。这可能会导致更多的混乱，而不是不透明的代码。
[顺便说一句，这就是为什么某些人更喜欢使用Persistent uniform resource locators在基础Web资源发生更改时提供弹性的原因。以类似的方式，当应用程序数据更改时，这些“代码”提供了弹性。