Channels ▼
RSS

Design

Graphs Versus Objects

Source Code Accompanies This Article. Download It Now.


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.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 

Video