Â¥Ö÷

[·ÖÏí]ÔÚSesameÖÐʹÓù¹³É²éѯµÄ¼òµ¥¹æÔò Simple rules using construct queries in Sesame ×÷ÕߣºJeen Broekstra 2009-10-8 A while ago I put together a simple rule-based reasoner for Sesame 2 (available in Aduna's Sesame extension SVN). The idea was to have a configurable rule-based reasoner that would reuse Sesame's query engine (in combination with SeRQL/SPARQL CONSTRUCT queries) to perform simple customized entailment. The idea is fairly simple: the reasoner works as a stacked SAIL in Sesame's repository configuration (the SAIL is a Sesame internal api that wraps the physical data storage medium). Rules are defined in an RDF format that reuses SeRQL syntax for defining graph patterns. By adding these rules to the Sesame repository the reasoner picks up on them, creates actual SeRQL CONSTRUCT queries out of these rules and then uses Sesame's own query engine to execute the rules, adding the rule result back into the repository. For example, a rule defining that an uncle of some person P is the brother of one of the parents of P would look like this (using Turtle syntax): ex:defUncle a custom:Rule;    rdfs:comment "my parent's brother is my uncle";    custom:head "{X} ex:uncleOf {Y}";    custom:body "{X} ex:brotherOf {} ex:parentOf {Y}" . The reasoner would translate this to the following SeRQL query: CONSTRUCT {X} ex:uncleOf {Y} FROM {X} ex:brotherOf {} ex:parentOf {Y} For those of you not familiar with SeRQL, the SPARQL equivalent would look like this: CONSTRUCT {?X ex:uncleOf ?Y } WHERE {?X ex:brotherOf ?Z.  ?Z  ex:parentOf  ?Y. } I've recently returned to this reasoner, for use in the Tiffany project. In this project, we are developing a Research Management System for researchers in the food industry, and one core concept in this system is a hierarchy of Research Questions and associated activities. Each activity is used by at least one team, and we need to keep a number of things up to date. For example, if a Research Question has an associated activity that is used by team X, the research question itself should also be marked as "used by team X". Moreover, if a research question A has a subquestion B, and that subquestion is used by team X, then research question A should also be marked 'used by team X'. Previously we tried to support this from code, by explicitly calculating and asserting RDF triples for the 'isUsedBy' relation whenever an activity is linked to (or unlinked from) a research question, or whenever the research question hierarchy is changed. However, the seemingly simple rules for entailment of isUsedBy quickly become devilishly complex when implemented in an imperative fashion. The function that deals with this is well over 100 lines of code. Now, compare that to the rule-based approach: tifrule:activityUsedBy a custom:Rule ;     custom:body "{X} tifn:activity {Y} tifn:isUsedBy {T} " ;     custom:head "{X} tifn:isUsedBy {T} " . tifrule:inheritanceUsedBy a custom:Rule ;     custom:body "{X} rdf:type {tifn:ResearchQuestion} ;                      tifn:isUsedBy {T} ,              {Y} tifn:hasSubQuestion {X} " ;     custom:head "{Y} tifn:isUsedBy {T} " Simple. And from some early tests I ran, remarkably good performance too. Next steps are to investigate how the performance of the approach holds up when I add more rules, and when I start doing many updates on the repository (after all, it's nice if querying is quick, but we also expect users to add new data or update existing information, and that requires that we do not have a large performance penalty for updates).    Êղؠ  ·ÖÏí   ¶¥(0)

----------------------------------------------
ºè·á