Dr. Dobb's Journal - July 2008 - (Page 35)

"PurchasableItem")); Literal manufacturer = m.createTypedLiteral("Dualit", XSDDatatype.XSDstring); m.add(toaster, m.getProperty(defaultNS, "hasManufacturer"), manufacturer); // similar code follows for hasCost // John Resource john = m.createResource(defaultNS + "johnHebeler"); m.add(john, RDF.type, m.getResource(defaultNS + "Person")); m.add(john, RDFS.label, m.createTypedLiteral("Matt Fisher", XSDDatatype.XSDstring)); // is buying the toaster Resource sale = m.createResource(defaultNS + "toasterSale"); m.add(sale, RDF.type, m.getResource(defaultNS + "Transaction")); m.add(sale, m.getProperty(defaultNS, "containsItem"), toaster); // similar code follows for hasBuyer, hasSeller // very soon! Literal sellingDate = m.createTypedLiteral("2008-03-24T10:00:00", XSDDatatype.XSDdateTime); m.add(sale, m.getProperty(defaultNS, "hasSellDate"), sellingDate); The resulting output is: John has purchased 1 item(s) John has bought: High-wolf shiny toaster At this point, we’re ready for real queries: // Now, how many items has John bought? ( // without using a special purpose query language) ResIterator junk = m.listSubjectsWithProperty(m.getProperty(defaultNS, "hasBuyer"), john); int count = 0; while (junk.hasNext()) { count++; junk.next(); } System.out.println("John has purchased " + count + " item(s)"); // Now, what has John bought? (using SPARQL) String queryString = "PREFIX rdf: " + // PREFIX rdf: "PREFIX rdfs: " // PREFIX rdfs: "PREFIX store: " // PREFIX store: "SELECT ?label " // SELECT ?label "WHERE { " // WHERE { " ?trans rdf:type store:Transaction . " // ?trans rdf:type store:Transaction . " ?trans store:containsItem ?item . " // ?trans store:containsItem ?item . ?item rdfs:label ?label . " // ?item rdfs:label ?label . " } "; // } // Take the SPARQL query and, using Jena's ARQ library // for SPARQL // build and execute the query Query query = QueryFactory.create(queryString) ; QueryExecution qexec = QueryExecutionFactory.create(query, m) ; try { ResultSet results = qexec.execSelect(); System.out.println("John has bought:"); while (results.hasNext()) { // Print out each item’s label, stripping off // the XSD type information QuerySolution soln = results.nextSolution(); String labelString = soln.getLiteral("label").toString(); int index = labelString.lastIndexOf("^^"); System.out.println(" "+ labelString.substring(0, index)); } } finally { qexec.close(); } Our queries are basic and don’t exploit all the graph properties— but they easily could. Integrating other graphs would be straightforward. If the graphs were based on a similar representation, we would not need to make any changes to our program. If the graphs were based on a different representation, we have two choices. We could make program changes similar to objects or, better yet, use a rule language such as the Semantic Web Rule Language (SWRL) to align the differences. For example, a rule could take advantage of the OWL’s equivalentClass construct. equivalentClass equates classes (“Automobile equivalentClass Car”) while OWL’s sameAs construct equates instances (“James sameAs Jim”). A rule representation maintains separation between the KR and its various translations for other representations. And with all this fun, we are not even touching on advanced constructs such as inference and advanced queries. This is only the beginning. “Hey, that’s a lot of code” you say and, well, you are right. , Much of this is structural and could be contained in an encapsulated programming class. Alternatively, all this data creation could be serialized in a file and merely read into the application, but this example provides a clearer handle as to what is happening behind the mirror. What you paid for in keystrokes pays off as we enter the agile part—the evolution. 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: July 2008 l www.ddj.com l Dr. Dobb’s Journal 35 http://www.ddj.com

Table of Contents Feed for the Digital Edition of Dr. Dobb's Journal - July 2008

Dr. Dobb's Journal - July 2008 Contents Friday Night Fish Fry Alia Vox Developer Diaries Developer’s Notebook Engineers Without Borders Conversations Patricia Tries Event-Based Architectures Graphs Versus Objects Lock-Free Queues Dr. Dobb’s Architecture & Design World Java and the Nokia N10 Internet Tablet Effective Concurrency The Agile Edge Swaine’s Flames

Dr. Dobb's Journal - July 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.