Wednesday, December 21, 2005
Spiral mySQL Schema
Semantic Planet :: Spiral mySQL Schema: "I've been reading Benjamin Novack's writing on exploding triple stores with interest and took some time to speak with him about it at ISWC this year. It prompted me ot take another look at the mySQL triplestore used by Spiral. This is a little write up of the design of that triplestore database.
First, let me explain a little about the RDF representation used in Spiral which might be a little different to other frameworks. Spiral is resource-centric rather than graph-centric. In concrete terms Spiral has a Resource class which has zero or more graph nodes associated with it. A graph node can only be associated with a single resource. Without smushing or reasoning each resource always has one node. The smushing process generally finds nodes that denote the same resource and so these associations can simply be updated.
The TripleStore interface provides various methods to deal with either resources or graph nodes and their associations. For example there's a GetResourceDenotedBy method which gives you the resource that a particular graph node denotes. Conversely there's a GetBestDenotingNode method which gives you a graph node for a particular resource. Generally this will give you a URI if the store knows of one, otherwise you'll get a blank node (I'm ignoring literals here). You can also get a list of all nodes for a resource using GetNodesDenoting. Finally you can build associations by using AddDenotation which takes a graph node and a resource pairing.
This is the model we wanted to follow when designing the mySQL support in Spiral. We already had a memory based triple store working well but we knew we wanted to support much larger persistent stores.
In Spiral a triplestore is equivilent to a named graph. Each mySQL database can store multiple triplestores. We use a Graphs table to partition the space. Each graph has a unique id. I'd like to see this changed to a URI to be more consistent with other implementations of named graphs."
First, let me explain a little about the RDF representation used in Spiral which might be a little different to other frameworks. Spiral is resource-centric rather than graph-centric. In concrete terms Spiral has a Resource class which has zero or more graph nodes associated with it. A graph node can only be associated with a single resource. Without smushing or reasoning each resource always has one node. The smushing process generally finds nodes that denote the same resource and so these associations can simply be updated.
The TripleStore interface provides various methods to deal with either resources or graph nodes and their associations. For example there's a GetResourceDenotedBy method which gives you the resource that a particular graph node denotes. Conversely there's a GetBestDenotingNode method which gives you a graph node for a particular resource. Generally this will give you a URI if the store knows of one, otherwise you'll get a blank node (I'm ignoring literals here). You can also get a list of all nodes for a resource using GetNodesDenoting. Finally you can build associations by using AddDenotation which takes a graph node and a resource pairing.
This is the model we wanted to follow when designing the mySQL support in Spiral. We already had a memory based triple store working well but we knew we wanted to support much larger persistent stores.
In Spiral a triplestore is equivilent to a named graph. Each mySQL database can store multiple triplestores. We use a Graphs table to partition the space. Each graph has a unique id. I'd like to see this changed to a URI to be more consistent with other implementations of named graphs."
0 Comments:
