• Founded in 2005; offices in Washington DC & Boston
• Customers in US Gov't, banking/financial, energy, health/bio, retail
• Strong academic partnerships in US, UK, Europe, and Mexico
• Expertise in
• Information Integration, Expertise Location, Policy Management, Enterprise Decision Support, Application Development
• OWL/RDF/SPARQL/SWRL

• Unify customer information: integrate all data about a customer as it's discovered
• Past, Present, and Future
• Pull from a variety of sources, including unstructured, many of which are non-relational
• Take advantage of flexible nature of semantic technology

• Capture the who-what-when-where-why-how of data throughout its lifecycle
• Utilize this information to enable data governance and regulatory compliance
  
• Annotate data as it comes in; continuously updated
• W3C spec dedicated to this: PROV

• Create a 'gold standard' for names, labels and identities
• Represent core industry terms and concepts
• Ties into Data Provenance
• Modeling complex relationships between entities can be trivial using semantic technology
• FIBO is a great example

• Reduce compliance efforts to query answering and graph analytics
• Legal regulations are complex
• And tracking related policies is a time consuming job
• Cost of implementation high, cost of a failure catastrophic
• Utilize reasoning & rules
• Express regulations and policies as complex relationships
• Workflows and compliance checking can be performed by a reasoner
• Automated compliance analysis with explanations

• Empower human decision making with contextualized, relevant information
• There is a lot of value in querying structured information automatically extracted from unstructured data
• As you build up structured corpus from data sources, you create actionable information
• Sift through the data to find the facts so a human can make decisions more quickly and easily

• All information integration problems
• i.e. not really financial services problems
• So how do you solve them?
• Specifically, what's the best way to perform information integration?
• Semantic Graphs
  

• Create graphs with meaning
• Encoded within the graph
• By giving formal, declarative definitions of the nodes and edges
• Using a high-level language
• Specifically, to create computer understandable meaning
• So the computer can help
• This lets us use the appropriate abstractions
• And is the obvious choice for information integration problems

• Let non-programmers perform complex information processing tasks without writing code
• More directly capture expertise
• By letting the actual experts author the business logic
• Easier and more maintainable for programmers, too
• Using the appropriate abstractions
• Inference rules & queries
  
• So the computer can do the work

• Leading RDF graph database
• Pure Java
• Enterprise, Developer, Community versions
• Great developer experience
• Rich feature set
• Currently version 2.2.4—3.0 due March 16th
• 59 public releases in 3 years (!)

• HA Cluster production-ready
• Improved read & write performance...in some cases 10x
• Equality reasoning via hybrid materialization
• only RDF database to support all of OWL 2
• ICV repair plans
• User extensible query aggregates, search analyzers
• LDAP integration
• Full (in-memory) DL reasoning
• Support for SPARQL SERVICE
• First class Maven support

• Property graphs & graph traverals via Apache Tinkerpop
• Docker support
• Named graph security
• Geospatial queries
• Cluster 2.0

• Backing Stardog with Apache Spark
• Data-center scalability with Yarn, Mesos, etc.
• Building a unified graph processing platform:
• Queries, rule reasoning, OWL
• Graph traversals
• Graph algorithms (shortest path, clustering, etc)
• Graph machine learning
• With a unified SPARQL interface for users

• HA Cluster: strong consistency guarantees (2PC)
• JMX server monitoring
• Hot Backup & Restore
  
• Access/Audit logging
• Web console built on Stardog Web Framework
• PROV and SKOS support
• ACID Transactions
• Rich Security model

• HA Cluster
• Active Replication
• 2PC-based commit protocol for strong consistency
• Writes processed by coordinator to determine order of operations
• Reads are distributed over all nodes

• Query
• Query 100M triples, thru-put: 4M+ queries per hour.  1B with ˜650k queries/hour and 10B with ˜50k queries/hour
• BSBM with 64 concurrent clients
• Scale
• ~50B triples/quads on modest hardware
• Load rates up to 500k triples/second
• 100M triples in 3 minutes, 1B in 30, and 20B in 20 hours.

• SPARQL 1.1
• Update, query, graph protocol
• Custom query planner, optimized for complex queries
• Targets BI/analytic queries
• And also reasoning
• But does not sacrifice performance at low scales or with simple queries
• Scalable query answering
• Intermediate results can get big, and fast
• Runtime will automatically flow results off-heap, and then to disk as needed
• Query management  
  

• First and foremost, we are developers too
• We intend for the best out of box experience possible
• Excellent documentation
• Easy installation, just unzip
• We <3 the command line
• Modeled after the Git command line, autocomplete support
• Like Java?  
• Jena, Sesame, Spring, SNARL?
• Prefer Javascript, Ruby, Python, .Net, Groovy, Clojure

• Embeds Lucene
• Automatically managed by database as if another RDF index
• Enables full-text searches over your RDF
  
• Literals are indexed by Lucene
• Uses the Lucene query language
• Extensible analyzer framework; customize stopword lists, language support, etc.
• Seamless integration via SPARQL
• Join results of full-text searches with regular SPARQL query
• Also available via SNARL Java API

• Version control is insanely useful
• Sometimes I wonder how people live without it
• So why not for an RDF database?
• Stardog adds commit management features similar to many popular VCS systems
• Add metadata, like comments, to commits
• Create tags
• Revert to a previous version
• Get diffs between versions
• Oh, all of this is stored as RDF
• So you can query your version history

• Make implicit information explicit
  
• Implicit in the schema, or data, or both
• Represent domain knowledge in a formal declarative model
• Called an ontology
• Like UML, but with formal semantics
• W3C specification called OWL, Web Ontology Language
• Reasoners consume ontologies to derive new information
• Answer queries, find inconsistencies
• Complex, but manageable
• OWL divided into profiles with less expressivity, but better computational properties 

• Unmatched OWL support
• All OWL2 profiles (RL, EL, QL, DL) and Stardog profile (SL)
• Caveats, no equality reasoning, no datatype reasoning, no DL reasoning over your ABox
• Query time reasoning
• No write performance penalty
• Pay for what you use
• Explanations
• Inference you don't understand?
• Reasoner will give you the proof used to derive it!
• Reasoning Services
• Consistency checking, satisfiability

• Stardog supports SWRL
• Part of the SL profile
  
• You cannot write it by hand, SWRL/RDF is unusable
• Much easier use Stardog Rules
• If-Then style rules based on SPARQL syntax:

PREFIX :
PREFIX math: 
IF {
    ?c a :Circle ;
         :radius ?r
    BIND (math:pi() * math:pow(?r, 2) AS ?area)
}
THEN {
    ?c :area ?area
} 

• Integrity Constraint Validation keeps data safe and consistent
• Prevent modifications that violate your integrity constrains
• 'Guard mode'
• Constraint violations abort transactions
• Also support 'oracle' mode, aka 'middleware' mode
• Outside of a transaction
• Check if data valid w.r.t some constraints
• Violations can be explained
• Inferences can satisfy or violate a constraint
• Constraints expressed in SPARQL, OWL, SWRL, or Stardog Rules
• High-level declarative languages make it easy to write simple constraints, possible to write complex ones

Supervisor subClassOf supervises some Employee  

• If you are using ICV
• You may not understand why a violation occurred
• Or want to communicate it to the user
• Explanations
• Tells you why the violation occurred
• Shows exactly the data that caused the violation
• Gives you the proof used to derive the violation

Project and (fundedBy only InternalFundingSource) subClassOf approvedBy value InternalBudgetOffice 

select * where { 
    ?x a Project . 
    FILTER NOT EXISTS {
        ?x fundedBy ?y . 
        FILTER NOT EXISTS { 
            ?y a InternalFundingSource 
        } 
    } . 
    FILTER NOT EXISTS {
        ?x approvedBy InternalBudgetOffice 
    } 
} 

• Coming in Stardog 3.1
• RDF graphs are still just graphs
• Graph measures: in-degree, out-degree, PageRank, betweenness centrality
• Clustering: weak/strongly connected components, clique finding
• Path finding: BFS and shortest path
• Seamless SPARQL integration
• Adding support for (de facto) graph standard: TinkerPop 3
• Native implementation for Gremlin, TinkerPop 3

• In Stardog 2.0 we added the Web Console
• Expose the features of the stardog  CLI in an easy to use web interface
  
• Add/Remove data, execute queries, etc.
• Or simply browse your data
• In 2.2, we added an administrative web console
• Create and drop database, manage security, etc.
• Everything you can do via the stardog-admin  CLI

• Transactions
• ACID
• Guarded (optionally) by ICV
• 2 Phase Commit over all database components
• RDF Index, Lucene, KB, etc.
• Automatically managed by the database
• Security
• RBAC model
• Based on Apache Shiro
• R/W ACLs for access to individual databases
• Administrative controls for actions against DBMS
• Online/offline a database, modify security settings, etc.

• For example, enforcing security (ACLs)
• Can Bob access Resource1?

Bob is-a Admin OR Bob created Resource1 OR (Bob hasRole ?r AND ?r canAccess Resource1) OR ... 

• Hard to maintain, encoded domain knowledge into the query
• Can leverage reasoning to simplify

Bob canAccess Resource1 

• More concise and maintainable
• Reasoner handles the implementing logic transparently