Knowledge Representation and Reasoning with Apache Stanbol


Published on

Knowledge Representation and Reasoning layer of Apache Stanbol

  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Knowledge Representation and Reasoning with Apache Stanbol

  1. 1. Knowledge RepresentationSemantic CMS Community and Reasoning with Apache Stanbol Project Review Andrea Nuzzolese Meeting Luxemburg, 14-03-2013 STLab, ISTC-CNR Co-funded by the Italy European Union
  2. 2. What does KR and Reasoning layer provide to Sanbol?›  Services used to define and manipulate semantic data models in the CMS ›  i.e., Ontology Network Manager component›  Services able to retrieve additional semantic information about content ›  i.e., Reaoners and Rules components Copyright IKS Consortium 2
  3. 3. Copyright IKS Consortium 3
  4. 4. Ontology Network Manager: motivations›  To enable a more scalable reasoning by ›  activating only parts of the knowledge that is really needed by the application ›  limiting the scope of specific reasoning tasks.›  To distinguish between core and volatile knowledge ›  core knowledge describes the semantic domain of the CMS ›  volatile knowledge can be any knowledge coming from external services, or extracted from contents etc. Copyright IKS Consortium 4
  5. 5. Ontology Network Manager›  The Ontology Network Manager provides a controlled environment for managing ontology networks›  An ontology network is “a collection of ontologies related together through a variety of different relationships such as mapping, modularization, and versioning.” [NeOn D1.1.5 Haase et. al]›  The ONM provides API and REST services for constructing ontology networks and maintaining connectivity at runtime Copyright IKS Consortium 5
  6. 6. Copyright IKS Consortium 6
  7. 7. Ontology networks in Stanbol›  The ONM relies on two types of artifacts for constructing ontology networks ›  Scope: ›  a shared artifacts within the CMS for collecting all the persistent knowledge. ›  can be seen as a "logical realm" for the ontologies that encompass a certain CMS-related set of concepts e.g., "User", "Event", "Content”, "Community”, ›  Session : ›  a shared artifact for volatile knowledge e.g., knowledge extracted on-the-fly from content Copyright IKS Consortium 7
  8. 8. Scopes and sessions in thOntology Network Manager Copyright IKS Consortium 8
  9. 9. Ontology Network Manager REST services›  /ontonet/ontology/{scopeName} ›  - {scopeName} list (GET), delete (DELETE) all registered and/or active ontology scopes ›  + {scopeName} get or activate, delete or deactivate, create (PUT) and update (POST) the ontology of the scope identified by {scopeName}›  ontonet/session/{id} ›  -{id} get, delete all registered ontology sessions ›  + {id} get, delete, create (PUT) and update (POST) the ontology session identified by {id} Copyright IKS Consortium 9
  10. 10. Stanbol Rules›  Stanbol Rules is the component that supports the construction and the management of inference rules within Stanbol›  Stanbol Rules provide an additional layer and a syntax for expressing business logics by means of axioms›  The management of rules is performed through HTTP REST services Copyright IKS Consortium 10
  11. 11. Rules and Recipes›  Rules are organized into a logic container called recipe›  A recipe identifies a set of rules that share the same business logic ›  e.g., integrity check of data, Search Engine Optimizaion›  Rules within a recipe are interpreted and executed as a whole›  A rule can be shared by different recipes Copyright IKS Consortium 11
  12. 12. Stanbol Rules: some usage scenario›  Integritycheck from data fusion ›  the CMS administrator can define integrity checks for data fetched from heterogeneous and external sources in order to prevent unwanted formats or inconsistent data›  Vocabulary harmonization ›  Rules can be used for the alignment of external data representation to internal one (managed via the Ontology Network Manager)›  DL reasoning ›  Rules can be used as axioms for inferring new knowledge by DL reasoners Copyright IKS Consortium 12
  13. 13. Stanbol Rules adapters›  Stanbol Rules are expressed by using the Stanbol Rule language›  By need, rules are converted at runtime to the format required by a concrete rule engine›  By default, a list of rule adapters is provided ›  i.e., SWRL for DL reasoning through OWL API, Jena Rules, Clerezza SPARQL Constructs, pure SPARQL Constructs›  Adapterscan be easily extended by implementing the provided interface Copyright IKS Consortium 13
  14. 14. The rule language›  The rule syntax synoptic is ruleName[body -> head]›  The rule name uniquely identifies a rule›  The body and head consist of a set of conjunctive atoms Copyright IKS Consortium 14
  15. 15. Core rule atoms›  Core atoms are ›  Class assertion ›  i.e., is(classPredicate, argument) ›  Individual assertion ›  i.e., has(properyPredicate, arg1, arg2) ›  Data value assertion ›  i.e., values(properyPredicate, arg1, arg2) Copyright IKS Consortium 15
  16. 16. Additional rule atoms›  Comparison ›  e.g., same(arg1, arg2), greaterThan(arg1, arg2)›  String manipulation ›  e.g., concat(arg1, arg2), lowercase(arg)›  Arithmetical atoms ›  e.g., sum(arg1, arg2), mult(arg1, arg2)›  Production atoms ›  e.g., newIRI(arg1, arg2), newLiteral(arg1, arg2) Copyright IKS Consortium 16
  17. 17. A rule exampleprefix myont = <> .uncleRule[ is(myont:Human, ?x) . has(myont:hasParent, ?x, ?z) . has(myont:hasSibling, ?z, ?y) -> has(myont:hasUncle, ?x, ?y)] Copyright IKS Consortium 17
  18. 18. Rules REST services›  /rule ›  get, create (POST), and delete rules into the rule store›  /recipe ›  get,create (PUT), add rules into (POST), and delete a recipe Copyright IKS Consortium 18
  19. 19. Stanbol Reasoners›  Common REST wrapper around available reasoners›  Provides a default reasoner based on Jena›  Other reasoners can be plugged through the OWLLink protocol Copyright IKS Consortium 19
  20. 20. Reasoning services›  Currently implemented services are ›  consistency checking ›  classification ›  enrichment ›  refactoring›  Inputs for reasoning are ontology networks and rules recipes›  Supported different reasoners and reasoning configuration in parallel Copyright IKS Consortium 20
  21. 21. Dealing with big data reasoning›  Reasoning with big data is performed by means of jobs through HTTP services›  A job is associated to an ID›  The status of a job can be queried through REST API Copyright IKS Consortium 21
  22. 22. Reasoners REST services›  Services for classification, consistency checking and enrichment ›  /reasoners/rdfs: based on RDFS ›  /reasoners/owlmini: by default based on Jena OWLMini reasoner. ›  /reasoners/owl: by default based on Jena OWL reasoner.›  Refactoring services ›  /refactor/apply›  Managing reasoning jobs ›  /jobs/{jid} Copyright IKS Consortium 22
  23. 23. About adoption›  Netlab ›  Adoptionof the Ontology Manager and Rules for storing ontologies and enabling reasoning›  InSideOut10 ›  WordLiftplug-in for WordPress based on Rules for enabling compliant content›  Acuity Unlimited ›  KR&R enables reasoning services to assist Fedora Commons repository managers acquire and manage semantic metadata about their contents Copyright IKS Consortium 23
  24. 24. Copyright IKS Consortium 24
  25. 25. Thank Copyright IKS Consortium 25