title: Graph Databases vs Triple Stores - when to use which?
body: <p>I know that there are similar questions around on Stackoverflow but I don't feel they answer the following.</p>
  
  <p>Graph Databases to my understanding store data following mostly this schema:</p>
  
  <pre><code>Table/Collection 1: store nodes with UID
  Table/Collection 2: store relations referencing nodes via UID
  </code></pre>
  
  <p>This allows storing arbitrary types of graphs. Now as I understand triple stores store nothing but triples:</p>
  
  <pre><code>Triple/Collection 1: store triples (2 nodes, 1 relation)
  </code></pre>
  
  <p>Now I would see the following distinction regarding use cases:</p>
  
  <ul>
  <li>Graph Databases: when you have known, static connections </li>
  <li>Triple Stores: when you have loosely connected nodes and are often looking for new connections</li>
  </ul>
  
  <p>I am confused by the fact that people do not seem to be discussing which one to use according to these criteria. Most article I find are talking about arguments like speed or compatibility. But is this not the most relevant point?</p>
  
  <p>Put the other way round:</p>
  
  <ul>
  <li>Imagine having a clearly connected, user defined graph. Why on earth would you want to store that as triples only, loosing all the info about connections? Or having to implement some custom solution storing IDs in the triple <code>subject</code>.</li>
  <li>Imagine having loosely collected nodes that you want to query for unknown relations using SPARQL. Graph databases do support that. But for this they have to build another index I assume and would be slower?</li>
  </ul>
  
  <p>EDIT:
  I see that "loosing info about connections" is the wrong way to put it. If you do as shown in the accepted answer and insert several triples for 2 nodes + 1 relation then you keep all the info and specifically the info what exact nodes are connected.</p>