Graphs Versus Objects

Expanding and Evolving

Now that our store is a booming success, we want to improve our post-sales tracking. Instead of just knowing that a transaction has occurred and something has been sold, we want to know which items are perishable and those that are not. At first, we should use objects and extend PurchasableItem with a new subclass, such as PurchasablePerishableItem. However, if we need perishable items elsewhere in our system that have nothing to do with purchasing (handling returned perishable items, archive of previously sold perishable items, and so on), then we would need to duplicate this class under another superclass (not all perishable items are always considered "purchased"). With graphs, we extend the containsItem property to containsPerishableItem and create a new PerishableItem class, which is not subclassed to PurchasableItem.

It's a little strange at first thinking about having subproperties, since a property is visually interpreted as a link between two nodes. Returning to the concept of triples, it becomes more manageable. The following is a declaration of our new subproperty and class in abbreviated RDF/XML:

<rdf:Description rdf:about="#containsPerishableItem">
   <rdf:type rdf:resource="http://www.w3.org/2002/07/owl#ObjectProperty"/>
   <rdfs:subPropertyOf rdf:resource="#containsItem"/>
</rdf:Description>
   ...
<owl:Class rdf:ID="PerishableItem">
   <rdfs:subClassOf rdf:resource="http://www.w3.org/2002/07/owl#Thing"/>
</owl:Class>

We can now sell that rotten lemon that has sat in the refrigerator for so long:

Resource lemonSale = m.createResource(defaultNS + "lemonSale");
  m.add(lemonSale, RDF.type, m.getResource(defaultNS + "Transaction"));
  m.add(lemonSale, m.getProperty(defaultNS, "containsPerishableItem"), lemon);
  m.add(lemonSale, m.getProperty(defaultNS, "hasBuyer"), john);
  m.add(lemonSale, m.getProperty(defaultNS, "hasSeller"), seller);

Now we can query for all perishable items sold (looking for all triples with property containsPerishableItem) or simply all items sold:

String queryString = "PREFIX store: <" + defaultNS + "> "          // PREFIX store: <http://www.example.com/storeOntInference#
      "SELECT ?item "  // SELECT ?item
      "WHERE { "       // WHERE {
      "       ?trans store:containsItem ?item ." ?  
      //      ?trans store:containsItem ?item .
      "      } ";      //       }

which returns:

<http://www.example.com/storeOntInference#shinyToaster>
<http://www.example.com/storeOntInference#lemon>

Several points should be clarified. Lemon's rdf:type value is inconsequential here; it is only perishable because it is part of the containsPerishableItem relationship. It is important to note that graphs won't return any compile-time or runtime errors, such as if I sell my gorilla suit online and incorrectly add it as part of a containsPerishableItem property. Our lemon instance automatically becomes an item involved in a transaction by using containsItem or any of its subproperties. This is the spirit of Web 2.0: Our store will forever sell items of all shapes and sizes, including those we never anticipated, always an agent of change. We can easily create new ways to query this knowledge to better understand and grow our business. Refactoring object code on a frequent basis to support such dynamic activity becomes burdensome. Realistically, we can never plan for all the different items our clients will buy and sell; graphs let us better deal with such uncertainty. Scalability, flexibility, and ease of integration are easily met using the graph paradigm, for the intelligence is in the data and not the code.

Conclusion

Now that you have a basic foundation of graphs, we hope you'll join us in expanding on graph possibilities including graph design, powerful queries, inference, alignment between graphs, distributed graphs, mapping to web services, and much more.