Opening Sesame with Networked Graphs

Simon Schenk just recently gave me an update to his Networked Graphs library for the Sesame RDF Framework. Even though it is in early alpha state the jars have already worked wonders on my Beatnik Address Book. With four simple SPARQL rules I have been able to tie together most of the loose ends that appear between foaf files, as each one often uses different ways to refer to the same individual.

Why inferencing is needed

So for example in my foaf file I link to Simon Phipps- Sun's very popular Open Source Officer - with the following N3:

 :me foaf:knows   [ a foaf:Person;
                    foaf:mbox_sha1sum "4e377376e6977b765c1e78b2d0157a933ba11167";
                    foaf:name "Simon Phipps";
                    foaf:homepage <http://www.webmink.net/>;
                    rdfs:seeAlso <http://www.webmink.net/foaf.rdf>;
                  ] .
For those who still don't know N3 (where have you been hiding?) this says that I know a foaf:Person named "Simon Phipps" whose homepage is specified and for which more information can be found at the http://www.webmink.net/foaf.rdf rdf file. Now the problem is that the person in question is identified by a '[' which represents a blank node. Ie we don't have a name (URI) for Simon. So when the Beatnik Address Book gets Simon's foaf file, by following the rdfs:seeAlso relation, it gets among others something like
[] a foaf:Person;
   foaf:name "Simon Phipps";
   foaf:nick "webmink";
   foaf:homepage </>;
   foaf:knows [ a foaf:Person;
                foaf:homepage <http://www.buzzword-compliant.com/>;
                rdfs:seeAlso <http://www.buzzword-compliant.com/foaf.rdf>;
             ] .
This file then contains at least two people. Which one is the same person? Well a human being would guess that the person named "Simon Phipps" is the same in both cases. Networked Graphs helps Beatnik make a similar guess by noting that the foaf:homepage relation is an owl:InverseFunctionalProperty.

Some simple rules

After downloading Simon Phipps's foaf file and mine and placing the relations found in them in their own Named Graph, we can in Sesame 2.0 create a merged view of both these graphs just by creating a graph that is the union of the triples of each .

The Networked Graph layer can then do some interesting inferencing by defining a graph with the following SPARQL rules

#foaf:homepage is inverse functional
grph: ng:definedBy """
  CONSTRUCT { ?a <http://www.w3.org/2002/07/owl#sameAs> ?b .  } 
  WHERE { 
       ?a <http://xmlns.com/foaf/0.1/homepage> ?pg .
       ?b <http://xmlns.com/foaf/0.1/homepage> ?pg .
      FILTER ( ! SAMETERM (?a , ?b))   
 } """\^\^ng:Query .
This is simply saying that if two names for things have the same homepage, then these two names refer to the same thing. I could be more general by writing rules at the owl level, but those would be but more complicated, and I just wanted to test out the Networked Graph sail to start with. So the above will add a bunch of owl:sameAs relations to our NetworkedGraph view on the Sesame database.

The following two rules then just complete the information.

# owl:sameAs is symmetric
#if a = b then b = a 
grph: ng:definedBy """
  CONSTRUCT { ?b <http://www.w3.org/2002/07/owl#sameAs> ?a . } 
  WHERE { 
     ?a <http://www.w3.org/2002/07/owl#sameAs> ?b . 
     FILTER ( ! SAMETERM(?a , ?b) )   
  } """\^\^ng:Query .

# indiscernability of identicals
#two identical things have all the same properties
grph: ng:definedBy """
  CONSTRUCT { ?b ?rel ?c . } 
  WHERE { ?a <http://www.w3.org/2002/07/owl#sameAs> ?b .
          ?a ?rel ?c . 
     FILTER ( ! SAMETERM(?rel , <http://www.w3.org/2002/07/owl#sameAs>) )   
  } """\^\^ng:Query .
They make sure that when two things are found to be the same, they have the same properties. I think these two rules should probably be hard coded in the database itself, as they seem so fundamental to reasoning that there must be some very serious optimizations available.

Advanced rules

Anyway the above illustrates just how simple it is to write some very clear inferencing rules. Those are just the simplest that I have bothered to write at present. Networked Graphs allows one to write much more interesting rules, which should help me solve the problems I explained in "Beatnik: change your mind" where I argued that even a simple client application like an address book needs to be able to make judgements on the quality of information. Networked Graphs would allow one to write rules that would amount to "only believe consequences of statements written by people you trust a lot". Perhaps this could be expressed in SPARQL as

CONSTRUCT { ?subject  ?relation ?object . }
WHERE {
    ?g tr:trustlevel ?tl .
    GRAPH ?g { ?subject ?relation ?object . }
    FILTER ( ?tl > 0.5 )
}
Going from the above it is easy to start imagining very interesting uses of Networked Graph rules. For example we may want to classify some ontologies as trusted and only do reasoning on relations over those ontologies. The inverse functional rule could then be generalized to
  PREFIX owl: <http://www.w3.org/2002/07/owl#>
  PREFIX : <https://sommer.dev.java.net/ontologies/beatnik#>

  CONSTRUCT { ?a owl:sameAs ?b .  } 
  WHERE { 
      GRAPH ?g { ?inverseFunc a owl:InverseFunctionalProperty . }
      ?g a :TrustedOntology .

       ?a ?inverseFunc ?pg .
       ?b ?inverseFunc ?pg .
      FILTER ( ! SAMETERM (?a , ?b))   
 }

Building the So(m)mer Address Book

I will be trying these out later. But for the moment you can already see the difference inferencing brings to an application by downloading the Address Book from subversion at sommer.dev.java.net and running the following commands (leave the password to the svn checkout blank)


> svn checkout https://sommer.dev.java.net/svn/sommer/trunk sommer --username guest
> cd sommer
> ant jar
> cd misc/AddressBook/
> ant run
Then you can just drag and drop the foaf file on this page into the address book, and follow the distributed social network by pressing the space bar to get foaf files. To enable inferencing you currently need to set it in the File>Toggle Rules menu. You will see things coming together suddenly when inferencing is on.

There are still a lot of bugs in this software. But you are welcome to post bug reports, or help out in any way you can.

Where this is leading

Going further it seems to me clear that Networked Graphs is starting to realise what Guha, one of the pioneers of the semantic web, wrote about in this thesis "Contexts: A Formalization and Some Applications", which I wrote a short note on Keeping track of Context in Life and on the Web a couple of years ago. That really helped me get a better understanding of the possibilities of the semantic web.

Comments:

Hi Henry,

Quick comment re: your owl:sameAs rule. I think you're missing some additional patterns.

So far you have "if A and B are the same, then A and B have the same properties", but for completeness you also need to say:

"if C refers to A, then C must also refer to B".

You probably don't need that for your examples, but thought I'd mention it for other people interested in the inferencing capabilities in CONSTRUCT

Posted by Leigh Dodds on March 07, 2008 at 12:29 PM CET #

Leigh Dodd's said:
> but for completeness you also need to say:
>"if C refers to A, then C must also refer to B".

yes, that would be expressed with the following rule.

CONSTRUCT { ?c ?rel ?b . }
WHERE {
?a <http://www.w3.org/2002/07/owl#sameAs> ?b .
?c ?rel ?a .
FILTER ( ! SAMETERM(?rel , <http://www.w3.org/2002/07/owl#sameAs>) )
}

Posted by Henry Story on March 10, 2008 at 10:33 AM CET #

Hi Henry,
I'm very greatful for the work you're doing. I find the write up very useful. Have you explained somewhere why you're using Networked Graphs as the reasoner? If not could you explain why, for instance instead of Pellet?

Posted by Adam Saltiel on May 10, 2008 at 05:41 PM CEST #

Hi Adam,

I don't think Pellet understands contexts. What NGSail gives me is the ability to create rules that depend on the contexts (Named Graphs). So I can say things like: please reason with the information from trusted contexts, that were fetched after a certain date, etc. etc....

But I may be wrong. I have not played with Pellet.... Perhaps there is a way of combining them?

Henry

Posted by Henry Story on May 10, 2008 at 08:11 PM CEST #

I have just svn'ed sommer and run it. Unfortunately it will not populate from the foaf. It is a big st and I don't have it all but it looks like Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
[java] at net.java.sommer.addressbook.FinderPanel$ListOfListPanes$2.next(FinderPanel.java:413)

I will try from within eclipse and see if I get any further. I notice that eclipse wants jetty, but I didn't notice jetty in the libs, maybe it is somewhere else?
I am trying to understand the way reasoning is used, and how it is used. What you have said indicates that Pellet is not generic or not sufficiently generic, or possibly that it is too generic and that this makes it difficult to use it for a specific task? I assume these are the difficulties with all reasoners? This would indicate that one of the difficulties with semantic web adoption is that of the use of reasoners, a different set of knowledge is required and even then it is difficult to apply it. An approach might be to have many specialised reasoners for different readily identifiable functions rather than very generic ones? But really I don't know what I'm talking about, it is speculation.

Posted by Adam Saltiel on May 10, 2008 at 08:46 PM CEST #

Adam,

it could be that your foaf is too big, or did not parse somehow. Let me know what the problem is. I am too tired today to look into it.

The missing Jetty should not be a problem for the Address Book. That is a dependency of the project Toby Inkster and I just started in the

misc/FoafServer

directory, which is not finished yet. It is to test the protocol described in

http://blogs.sun.com/bblfish/entry/foaf_ssl_creating_a_global

So you don't need that.

Posted by Henry Story on May 10, 2008 at 09:34 PM CEST #

Hi Henry:

I don't "get" this post about using Networked Graphs. What is it giving us that we don't get from any vanilla reasoner.
If all we need to say is foaf:homepage is an IFP, I can do it in any reasoner...

Insights would be helpful.

Revi

Posted by Revi on May 12, 2008 at 03:20 PM CEST #

Revi said:
> What is it [Networked Graphs] giving us that we don't get from any vanilla reasoner.

You can describe the relations between all the objects in the universe from big bang to the end with triples. Call this the full description of a possible world. [1] You could put all these in a big graph that would be the total description of reality.

When you have just 2 people who disagree on one fact, what is it that they are disagreeing on? They are disagreeing on which of two possible worlds is the true one. Since when we get information off the net we can't always tell which people are in agreement, we put their statements into different graphs, and specify where that information come from. We can then merge all or some of the graphs, and see what conclusions we come to.

Normal OWL reasoning is reasoning within a graph. It helps us come to monotonic conclusions from the information we had initially. If

:p1 foaf:knows :p2 .

then we can conclude that

:p1 a foaf:Person .
:p2 a foaf:Person .

and much more. But if one person claims that :p1 is a document, and someone else that it is a person, then all owl can tell us is that we have a contradiction somewhere. At that point we need to know what information to remove. We need to keep track of where we got it.

So NG allows us to specify rules on how to merge information into a new graph. It can also be used as an OWL reasoner within that graph.

Hope that helps,

Henry

[1] http://blogs.sun.com/bblfish/entry/the_fifth_dimension

Posted by Henry Story on May 12, 2008 at 05:38 PM CEST #

Thanks Henry for the nice explanatory note. A couple of points:

1.
Henry said:
> Normal OWL reasoning is reasoning within a graph.

I'm not sure what you mean by normal reasoning is within a graph. I don't think we in the community assume there will be ONE giant graph we will reason with. The normal model in a federated world is in fact to use multiple graphs from multiple sources. The SPARQL standard allows you to query as many sources as you want using multiple FROM and FROM NAMED.

2.
Henry said:
> OWL can tell us is that we have a contradiction somewhere. At that point we need to know what information to remove.

With the open-world assumption of the SW, there will always be the possibility of new assertions introducing conflicts. (I don't mean to start the monotonic/non-monotonic reasoning approach debate). One way to mitigate is to use provenance to make a decision, such as all the variations of quad-store strategies proposed.
But I still don't get how using a priori "rules" in NGs can prevent conflicts -- provenance information is certainly not a guarantee for consistent assertions. I could add matching rules (say based on domain assumptions) to my off-the shelf reasoner today, and get the same functionality. What "networked graphs" give me beyond that is still not clear. Is NG making us commit before-hand as to what sub-graphs we will be merging?

Revi

Posted by Revi on May 12, 2008 at 06:37 PM CEST #

Revi said:

[[
But I still don't get how using a priori "rules" in NGs can prevent conflicts -- provenance information is certainly not a guarantee for consistent assertions. I could add matching rules (say based on domain assumptions) to my off-the shelf reasoner today, and get the same functionality. What "networked graphs" give me beyond that is still not clear. Is NG making us commit before-hand as to what sub-graphs we will be merging?
]]

Yes, NG rules are not a guarantee of consistent assertions. Their contribution is very simple: NG rules, which are really just SPARQL CONSTRUCT queries, allow you to make rules of which graphs to merge, which ontologies to use, etc.... You can define a view over a number of graphs in your quad store. Different sets of rules will give you different views over your information.

Posted by Henry Story on May 12, 2008 at 07:14 PM CEST #

Post a Comment:
Comments are closed for this entry.
About

bblfish

Search

Archives
« July 2014
MonTueWedThuFriSatSun
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
   
       
Today