1 / 13

Features of an Enterprise-ready Triple Store

Features of an Enterprise-ready Triple Store. Ben Szekely June, 2006. Most examples of RDF triple stores focus on specific difficult problems. Focused on inference or standards Preoccupied with “Billions of Triples” Little thought given to application programming model.

tyler
Download Presentation

Features of an Enterprise-ready Triple Store

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Features of an Enterprise-ready Triple Store Ben Szekely June, 2006

  2. Most examples of RDF triple stores focus on specific difficult problems • Focused on inference or standards • Preoccupied with “Billions of Triples” • Little thought given to application programming model. • Not multi-user (limited security)

  3. Selective RDF replication from server to client machines Security, including named-graph-based RDF access control Audit trails of changes to data within named graphs Near real-time event notifications Sophisticated programming model Boca Overview – Multi-user, distributed enterprise RDF repository

  4. Named Graphs • A named graph is the logical unit of RDF storage in Boca. • Each triple exists in exactly one named graph • If a triple exists in more than one named graph, it exists twice. • Adding and removing triples is done in the context of a named graph • Each named graph has a metadata graph, containing information such as ACLs • Named graphs can be exposed via LSIDs, URLs, Web Services • Named Graph applications • LSID metadata • Workflow documents • Atom feeds • FOAF profiles

  5. Underlying Technologies • Relational Database (DB2, Oracle, MySQL) • RDF triples stored in a table (subject, predicate, object, graphid) • Space saved by normalizing URIs and strings to integer ids. • Extra tables for history, ACLs, replication • J2EE (Jetty, Tomcat, WebSphere) • Jetty: Standalone server, checkout from CVS and run for testing • WAS: Enterprise-ready Web-application server for real deployment • JMS Server (Active MQ, WebSphere MQ) • pub-sub messaging used for real-time notifications of triple updates.

  6. Replication • Boca clients have a persistent local RDF store that mirrors a subset of the triples on the Boca server. • Replicated subset specified by: • Triple patterns; e.g.(<http://tdwg.org/meetings/GUID-2#>, <http://tdwg.org/preds/hasParticipant>,*) • Named graph URIs • Triple patterns within named graphs • When a replication is initiated, the service computes what has changed in the subset based on pattern and graph subscriptions. • Replication can work as a background process on the client, or be explicitly initiated. • Applications can query/write against graphs in the local and server models.

  7. Notification – maintaining the replica in real-time • Updates to named graphs on server are published in near real-time to clients. • Local replicas can be kept up-to-date between replications. • Notification is central to distributed RDF applications • Ex: workflow, collaboration

  8. Access Controls • Boca uses can have the following system-wide permissions: • canInsertNamedGraphs -- a user must have this permission in order to create a new named graph (i.e. insert statements into a graph that does not yet exist in the system) • Boca users can have the following per-named-graph permissions (these apply also to the system graph): • canRead -- a user with this permission may view the triples in the named graph and in its metadata graph • canAdd -- a user with this permission may insert new triples into the named graph • canRemove -- a user with this permission may remove triples from the named graph • canChangeNamedGraphACL -- a user with this permission may change the ACL triples in the metadata graph • canRemoveNamedGraph -- a user with this permission may entirely remove the named graph from the system

  9. Versioning • SVN-like approach to versioning • When a triple is added to or removed from a named graph, a new revision of that named graph is created. • Simple API for reading old revisions • Provides a straightforward mechanism for concurrent distributed computing. • When a client submits an update to a named graph, it may specify the version number that it currently has. The update will fail if the graph has been more recently modified.

  10. The Boca Programming Model • Named Graphs • Commands • Transactions • Versioning • Replication • Notification

  11. Abandoned features – Collections, Statement ACLs & Reification • Collections – a statement can exist in multiple collections • A more difficult programming model, what happens when I delete in the context of one collection? • Expensive to maintain • Not a widely accepted programming model (as named graphs are) • Statement-level ACLs • Too expensive • Difficult to program • Not particularly useful, other than the odd, very important statement • In that case, such a statement can live in its own named graph • Reification • Queries were very difficult to formulate • Most RDF applications do not deal with reification • Reification semantics often confused with true quoting • Reification is an arbitrary layer of indirection that can be solved with ontologies

  12. Future Features • Arbitrary query-based replication/notification • Distributed servers • Open source

  13. Applications • Executing OWL-S in a distributed fashion • Storing annotations • Providing LSID metadata • Web 2.0 application backend • Wikis, Blogs, Tagging, Atom • National Cancer Institute research platform

More Related