例如：
entity:f06574 rdfs:label "Orioles"
或这样的格式：
:tt0268252 a :Movie .
无论哪种情况，f06574和tt0268252都是代码，而不是实体或实例的实际字符串。一个原因可能是由于相同的字符串可能引用了不同的事物，但是在RDF世界中，事物的标识符始终以其唯一的URI作为前缀，因此即使使用了字符串，也不会引起歧义。可读且不透明的代码。
这种表示形式的真正原因是什么？ Freebase中的三元组相似。
为什么在对象的RDF中使用代码而不是字符串？
•
问答
chaomi87 回答：为什么在对象的RDF中使用代码而不是字符串？
这与关系数据库理论中的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资源发生更改时提供弹性。这些“代码”以类似的方式在应用程序数据更改时提供弹性。