Inferencing/Reasoning

Let’s look at the first way of annotating individuals. This script creates a few publications (books) from the British National Library catalog sets a label on each of them. The labels match categories defined before.

Note that in this case there is no relationship connecting the books with the category they belong to. We are using labels instead. But there is an explicit hierarchy for these labels that we want to exploit.

What we want now is to be able to ask Neo4j for all the books on Crystallography and get all those actually labelled as Crystallography but also all those labelled as any of Crystallography’s subcategories. That’s exactly what the n10s.inference.nodesLabelled does for us. All we need to do is pass the details on how is the category hierarchy built: catLabel will contain the label used to describe categories (the default is Label) which in our case is LCSHTopic. We’ll also need to specify in the subCatRel parameter, the relationship used to define the hierarchy (the default is SLO for Sub Label Of) which in our case is NARROWER_THAN. Finally, we need to specify the name in the category node containing the label name (the default is name) which in our example is dbLabel.

When we run this query, and even thoug not a single node in our graph is actually labelled as Crystallography, we get the following results:

If what we are looking for is not an set of nodes in a given category but rather a predicate telling us whether a node is or not is in a category then the function we need is n10s.inference.hasLabel.

Let’s create a user with interests in some of the books in our database:

Now we can query for the books about Physical optics that he’s interested in.

Let’s first setup a parameter that defines the inference query:

And now we can run our query:

And again, even though there’s no book explicitly labelled as 'PhysicalOptics', the query will produce the following result:

Check the Reference section for a complete list of methods and configuration parameters for these methods and functions.

Now let’s look at the second way of annotating individuals.

This script creates a few of them and links them to the categories defined before.

In this case, the query to get the nodes in a particular category will make use of the n10s.inference.nodesInCategory procedure. This procedure takes as parameters, the details of how is the category hierarchy built and how are individuals connected to the categories: inCatRel specifies the relationship used to link an instance to a category (the default is IN_CAT) which in our example is HAS_SUBJECT. subCatRel specifies the relationship used to define the hierarchy (the default is SCO for Sub Category Of) which in our example is NARROWER_THAN.

When we run this Cypher fragment, we get the following list of results, even though not a single node in the graph is actually explicitly connected to the Crystallography category.

If what we are looking for is not an set of nodes in a given category but rather a predicate telling us whether a node is or not is in a category then the function we need is n10s.inference.inCategory.

Let’s create a user with interests in some of the books in our database:

Now we can query for the books about Physical optics that he’s interested in.

Let’s update our inference parameter by running the following query:

And now we can run the query:

And again, even though there’s no book explicitly connected to the 'PhysicalOptics' category, the query will produce the following result:

Remember to check the Reference section for a complete list of methods and configuration parameters for these methods and functions.

We can use the n10s.onto.import.fetch procedure to import the NCBI Taxon ontology. This is an ontology representation of the National Center for Biotechnology Information (NCBI) organismal taxonomy. It contains 1.8 million classes (Class) and 3.6 million subClass of (SCO) relationships.

Let’s add to the hierarchy a few individuals. Some dogs (NCBITaxon_9615, "Canis lupus familiaris"):

And why not? some mice (NCBITaxon_10092, "Mus musculus domesticus"):

If we’re looking for instances of mammals in our database, we’d look for nodes labelled as NCBITaxon_40674 ("Mammalia"). Obviously no node has been labelled as mammal, but we expect Neosemantics to do the job for us.

Only a few milliseconds needed to identify them in the nearly 11k categories under Mammalia.

Interestingly, and because Neo4j is a native Graph DB implementing index free adjacency, if we were to search across the 1.2 million categories for all instances of "Eukaryota" (NCBITaxon_2759), (one of the top three categories that all cellular organisms are divided into) it would take Neosemantics exactly the same time to identify them. Here’s the query:

Similarly, we can verify in milliseconds how many of an individual’s pets are actually instances of "Eukaryota". Here’s how:

Let’s take the movie database. Remember you can have it loaded in Neo4j by running :play movies and following the instructions in the guide. Let’s say we have a fragment of a movie ontology that contains a definition of a relationship hierarchy. It does it by defining a number of rdfs:subPropertyOf statements between relationships. For instance, it states that every ACTED_IN relationship is also a WORKED_IN one. This is the triple in question:

To see this inferencing procedure in action, we’ll start by loading the ontology. We can do this by either using the n10s.onto.import.fetch or the n10s.rdf.import.fetch methods described in the Importing RDF Data section.

If we run:

We should get a simple hierarchy of properties like the one in this screen capture from the Neo4j browser.

Writing a query that returns all nodes connected to the movie The Matrix through the 'virtual' WORKED_IN relationship is an easy task with the n10s.inference.getRels procedure.

Now let’s say we want to modify the meaning of the WORKED_IN relationship to exclude PRODUCED and keep only artistic involvement connections, tis is WROTE, ACTED_IN and DIRECTED. We don’t need to alter our database, just our ontology.

If we run the same query again, we’ll get different results, this time excluding producers. Think of this in a large scale DB. We can effectively modify relationships globally by adding or deleting a simple link to the hierarchy and without having to modify every single instance.