More on Semantic/RDF Properties.

Much has been said elsewhere on the web that Labeled Property Graphs (LPG) are more "natural" and more "efficient" than Semantic (RDF) graphs. I say: nonsense. Folks who make that claim simply know what they know and make up rationalizations to stand by their claim. For those of us who are a little more open-minded, RDF graphs can be just as "natural" and "efficient" -- the key is knowing how to make use of NamedGraphs to add properties to your RDF graph (see my previous post: www.ateam-oracle.com/semanticrdf-"properties")

Let's take a prominent example from our friends at Neo4J. Here they compare LPG to RDF using a simple example of a single LPG graph edge showing a travel connection to San Francisco from New York City. Note that price and distance are (quite naturally) properties of its edge. Contrast that with their illustrated RDF sample graphlet purportedly showing the same data -- using fully legal RDF, btw -- where they imply that this is the only way to model the same relationships in RDF without reification. (Not true, as we shall see below). Note that they've shown four triples in their overly-complicated RDF model instead of just one, in order to accommodate the two property values.

To quote the Neo4J guys regarding the above LPG vs. RDF comparison: "On the left is what I can do in the labeled property graph. Because we can’t create such a simple model in RDF, we [must] create an entity that represents the connection between New York and San Francisco."

Really?

Now if I were skimming their claim and not paying attention I too might come to the same conclusion they did. But as with most things, the devil's in the details. And as has been documented previously, we can leverage the RDF concept of NamedGraphs to add properties to our edges just as easily as any LPG.

Let's start by adding three triples to our data store (recalling that only objects can ever have non-URI values):

We have one triple -- just like LPG -- that denotes the connection relationship of NYC to SFO. We use the NamedGraph as a key for adding additional properties. Then we need to add two more triples to our store to add the price and distance properties, leveraging the same NamedGraph URI as the subject. 

So far, so good. However, with the behavior the typical RDF triple-store graph viewers out there (e.g. Cytoscape), we would likely see something like the following graph, showing the main triple  apparently disconnected from its "property" triples. Something of which is less than ideal for our business user

But with a simple change to the presentation layer code (typically written in JavaScript, btw) to aggregate our properties together with the original triple, our graph could then trivially appear like the following to the end user:

Presented this way, I'm not seeing much if any difference between the above aggregated RDF view and the original LPG view, do you? Didn't think so. More on this topic later.

SUMMARY

If we need "Propertly-like" features in our RDF graph applications, then all we need do is leverage the NamedGraph feature of RDF and make some minor code changes to our graph viewer to aggregate the properties together for business users. One could imagine the presentation layer being further enhanced to allow business users to add properties as needed to their edges via the GUI -- that would be really sweet! As stated in the previous blog, with Oracle's implementation of RDF there is no need to make any code changes to your SPARQL to enjoy the benefits of leveraging NamedGraphs for adding edge properties to your models.