I don&#x27;t see it is that different. A wiki page typically assigns human-readable properties through its text. You don&#x27;t write<p><pre><code>  &lt;a href=&quot;foo.html&quot;&gt;Read more&lt;&#x2F;a&gt;
  &lt;a href=&quot;bar.html&quot;&gt;Read more&lt;&#x2F;a&gt;
</code></pre>
but:<p><pre><code>  &lt;a href=&quot;foo.html&quot;&gt;Example code&lt;&#x2F;a&gt;
  &lt;a href=&quot;bar.html&quot;&gt;Grammar&lt;&#x2F;a&gt;
</code></pre>
If desired, one can even make this easier to parse programmatically:<p><pre><code>  &lt;a href=&quot;foo.html&quot; class=&quot;ExampleCode&quot;&gt;Hello world example&lt;&#x2F;a&gt;
  &lt;a href=&quot;bar.html&quot; class=&quot;GrammarNotes&quot;&gt;Grammar&lt;&#x2F;a&gt;
</code></pre>
That allows for styling different types of links differently. Also, a wiki&#x27;s backend software could extract separate indexes for sample code, grammar fragments, links to compiler source, etc. you could also easily include an attribute for, e.g. Click-through rate, and, if desired, style links accordingly.<p>In fact, the difference between a classical wiki and a graph database is, IMO, an implementation choice. If you want to process complex queries rapidly or a lot of your attributes aren&#x27;t textual or aren&#x27;t intended primarily for visual display, a graph database is more appropriate. If you want to serve standard web pages rapidly, storing the content as HTML may be more appropriate, even if that means that processing queries such as &quot;give me all links to source code examples&quot; run way more slowly.