What's the story here? Cells from the table have been converted into facts, but the order of the facts has been scrambled. We know that one of the boats finished in "5381793.0" seconds, and we know there was a boat named "Warta_Polpharma" and so forth, but we don't know which boats finished, which boats boats finished in what time, which boat had what skipper, etc.

This is not a limitation of RDF, but it is a common limitation of RDF-based systems in the "Linked Data" era, and it's historically been a problem in RDF.

The basic problem is that if we want to write a statement like the one on the first row of the HTML table, we end up having to write something like

<Some_Node> pr:pos 1 ; pr:boat <Club_Med> ; pr:skipper <Grant_Dalton> ; pr:nation "NZL" ; pr:time 5381793.0 . <The_Race_(yaching_race)> pr:entry <Some_Node> .

the only hard part is determing a name for <Some_Node> . In the case of DBpedia, names are derived from URIs in Wikipedia, a formula that doesn't apply when we're talking about a concept that doesn't have a URI in Wikipedia. We can duck the problem of assigning a name by using a blank node (which states a node exists without giving a specific name) but that causes problems of its own which come from the difficulty of having something nameless in a distributed system. (What if I want to talk about a nameless entity that exists in DBpedia?)

For specific problems, it's possible, and often straightforward, to find ways to name nodes like <Some_Node> . However, it is hard to find a solution that pleases everybody, particularly when we are talking about a system which is decentralized, in which people would like names to be stable over time, etc.

With conflicting demands, it's no wonder that this area has not been standardized by the W3C, but it's great to see that DBpedia is making some progress in this area, which I'll show in the next section.