diff options
author | Federico Igne <federico.igne@cs.ox.ac.uk> | 2021-04-15 12:32:45 +0100 |
---|---|---|
committer | Federico Igne <federico.igne@cs.ox.ac.uk> | 2021-04-15 12:32:45 +0100 |
commit | 826ef61338f8cf9c5c71fe2fd5b2ed82e0dabcf9 (patch) | |
tree | 1936a71db16fd9221389daf9d4454353754ac4d9 | |
parent | c6a63f565b8311348a800366c05dc3a6e964872c (diff) | |
download | RSAComb-826ef61338f8cf9c5c71fe2fd5b2ed82e0dabcf9.tar.gz RSAComb-826ef61338f8cf9c5c71fe2fd5b2ed82e0dabcf9.zip |
Prepare code for double-blind submissionv0.1.0
-rw-r--r-- | README.md | 24 | ||||
-rw-r--r-- | src/main/scala/uk/ac/ox/cs/rsacomb/CanonicalModel.scala | 4 | ||||
-rw-r--r-- | src/main/scala/uk/ac/ox/cs/rsacomb/RSAOntology.scala | 2 | ||||
-rw-r--r-- | src/main/scala/uk/ac/ox/cs/rsacomb/converter/RDFoxConverter.scala | 8 |
4 files changed, 12 insertions, 26 deletions
@@ -21,7 +21,7 @@ We assume you followed [these steps](https://docs.oxfordsemantic.tech/getting-st | |||
21 | 21 | ||
22 | The [documentation](https://docs.oxfordsemantic.tech/features-and-requirements.html#license-key), describes several ways to provide the license to RDFox. | 22 | The [documentation](https://docs.oxfordsemantic.tech/features-and-requirements.html#license-key), describes several ways to provide the license to RDFox. |
23 | 23 | ||
24 | One easy way is to put your license key in a file `RDFox.lic` in `$HOME/.RDFox/`, with adeguate read permissions for the user executing the program. | 24 | One easy way is to put your license key in a file `RDFox.lic` in `$HOME/.RDFox/`, with adequate read permissions for the user executing the program. |
25 | 25 | ||
26 | ### Compiling and running the project | 26 | ### Compiling and running the project |
27 | 27 | ||
@@ -48,21 +48,21 @@ Note that the fat jar file distributed with this repository excludes the RDFox a | |||
48 | java -cp <path/to/JRDFox.jar>:<path/to/fat.jar> uk.ac.ox.cs.rsacomb.RSAComb [<option> ...] | 48 | java -cp <path/to/JRDFox.jar>:<path/to/fat.jar> uk.ac.ox.cs.rsacomb.RSAComb [<option> ...] |
49 | ``` | 49 | ``` |
50 | 50 | ||
51 | ### Running tests and examples | 51 | ### Running tests |
52 | 52 | ||
53 | TODO | 53 | To run the suit of unit test provided along with the code run |
54 | ``` | ||
55 | sbt test | ||
56 | ``` | ||
54 | 57 | ||
55 | ## Changes introduced | 58 | ## Changes introduced |
56 | 59 | ||
57 | We tried to implement the system as close as possible to the theoretical description provided in [[1](#references)]. | 60 | We tried to implement the system as close as possible to the theoretical description provided in [[1](#references)]. |
58 | Regardless, we had to deal with the fact that we where using different tools to carry out reasoning tasks and we where probably using a different language to implement the system. | 61 | Regardless, we had to deal with the fact that we where using different tools to carry out reasoning tasks and we where probably using a different language to implement the system. |
59 | The following is a summary of fixes (🔧), changes (🔄) and improvements (⚡), we introduced along the way: | 62 | The following is a (non exhaustive) summary of fixes (🔧), changes (🔄) and improvements (⚡), we introduced along the way: |
60 | 63 | ||
61 | + 🔄 [RDFox](https://www.oxfordsemantic.tech/product) is used instead of DLV as the underlying LP engine. | 64 | + 🔄 [RDFox](https://www.oxfordsemantic.tech/product) is used instead of DLV as the underlying LP engine. |
62 | 65 | ||
63 | + 🔄 While the system is described as a two-step process (computing the canonical model and applying the filtering program), the adoption of RDFox allows us to abstract from the underlying engine implementation. | ||
64 | Materialisation is handled by RDFox, possibly computing answers in one go, without splitting the process in two separate steps. | ||
65 | |||
66 | + 🔧 In Def.4, the definition of built-in predicate `notIn` is wrong and should reflect the implicit semantics implied by the name, i.e., | 66 | + 🔧 In Def.4, the definition of built-in predicate `notIn` is wrong and should reflect the implicit semantics implied by the name, i.e., |
67 | 67 | ||
68 | > let [...] `notIn` be a built-in predicate which holds when the first argument is **not** an element of the set given as second argument | 68 | > let [...] `notIn` be a built-in predicate which holds when the first argument is **not** an element of the set given as second argument |
@@ -83,7 +83,6 @@ The following is a summary of fixes (🔧), changes (🔄) and improvements (⚡ | |||
83 | rsa:congruent[?X, ?Z] :- rsa:congruent[?X, ?Y], rsa:congruent[?Y, ?Z] . | 83 | rsa:congruent[?X, ?Z] :- rsa:congruent[?X, ?Y], rsa:congruent[?Y, ?Z] . |
84 | ``` | 84 | ``` |
85 | defining equivalence as a congruence relation over terms in the ontology. | 85 | defining equivalence as a congruence relation over terms in the ontology. |
86 | *Substitution rules have not been entroduced yet.* | ||
87 | 86 | ||
88 | + 🔧 In Def. 4, the definition of built-in predicate `NI` is not consistent with its use in Table 3 and related description in Sec. 4.2. | 87 | + 🔧 In Def. 4, the definition of built-in predicate `NI` is not consistent with its use in Table 3 and related description in Sec. 4.2. |
89 | We redefined `NI` as the set of all constants that are *equal* to a constant in the original ontology (according to the internal equality predicate `rsa:congruent`). | 88 | We redefined `NI` as the set of all constants that are *equal* to a constant in the original ontology (according to the internal equality predicate `rsa:congruent`). |
@@ -94,12 +93,13 @@ The following is a summary of fixes (🔧), changes (🔄) and improvements (⚡ | |||
94 | ``` | 93 | ``` |
95 | where `rsa:named` is an internal predicate keeping track of all constants in the original ontology. | 94 | where `rsa:named` is an internal predicate keeping track of all constants in the original ontology. |
96 | 95 | ||
97 | + âš¡ In Def. 3, regarding the generation of the logic program used for the RSA checkk, only T5 axioms involving an unsafe role will introduce the internal predicates `PE` and `U`. | 96 | + âš¡ In Def. 3, regarding the generation of the logic program used for the RSA check, only T5 axioms involving an unsafe role will introduce the internal predicates `PE` and `U`. |
98 | 97 | ||
99 | + âš¡ Both in the canonical model and the filtering program computations, rules without a body are loaded into RDFox as facts. | 98 | + âš¡ Both in the canonical model and the filtering program computations, rules without a body are loaded into RDFox as facts. |
100 | 99 | ||
101 | + ⚡ The `cycle` function introduced in Def.4 establishing the direction of the *unraveling* of loops is defined over triples `(A,R,B)`. We are currently limiting the triple only to those appearing in a T5 axiom `A ⊑ ∃R.B`. Note that this greatly limits the size of cycle for a given triple, and as a consequence limits the number of rules used to compute the canonical model. | 100 | + ⚡ The `cycle` function introduced in Def.4 establishing the direction of the *unraveling* of loops is defined over triples `(A,R,B)`. We are currently limiting the triple only to those appearing in a T5 axiom `A ⊑ ∃R.B`. Note that this greatly limits the size of cycle for a given triple, and as a consequence limits the number of rules used to compute the canonical model. |
102 | 101 | ||
102 | |||
103 | ## References | 103 | ## References |
104 | 104 | ||
105 | [1] Feier, Cristina, David Carral, Giorgio Stefanoni, Bernardo Cuenca Grau, and Ian Horrocks. | 105 | [1] Feier, Cristina, David Carral, Giorgio Stefanoni, Bernardo Cuenca Grau, and Ian Horrocks. |
@@ -109,12 +109,12 @@ The following is a summary of fixes (🔧), changes (🔄) and improvements (⚡ | |||
109 | 109 | ||
110 | ## Acknowledgements | 110 | ## Acknowledgements |
111 | 111 | ||
112 | TODO | 112 | *temporarily redacted* |
113 | 113 | ||
114 | ## Credits | 114 | ## Credits |
115 | 115 | ||
116 | TODO | 116 | *temporarily redacted* |
117 | 117 | ||
118 | ## License | 118 | ## License |
119 | 119 | ||
120 | TODO | 120 | *temporarily redacted* |
diff --git a/src/main/scala/uk/ac/ox/cs/rsacomb/CanonicalModel.scala b/src/main/scala/uk/ac/ox/cs/rsacomb/CanonicalModel.scala index 3da6c8a..6621f59 100644 --- a/src/main/scala/uk/ac/ox/cs/rsacomb/CanonicalModel.scala +++ b/src/main/scala/uk/ac/ox/cs/rsacomb/CanonicalModel.scala | |||
@@ -118,10 +118,6 @@ class CanonicalModel(val ontology: RSAOntology) { | |||
118 | .getIRI | 118 | .getIRI |
119 | TupleTableAtom.rdf(v0, IRI.RDF_TYPE, cls) | 119 | TupleTableAtom.rdf(v0, IRI.RDF_TYPE, cls) |
120 | } | 120 | } |
121 | // TODO: To be consistent with the specifics of the visitor we are | ||
122 | // returning facts as `Rule`s with true body. While this is correct | ||
123 | // there is an easier way to import facts into RDFox. Are we able to | ||
124 | // do that? | ||
125 | val facts = unfold map RSA.In | 121 | val facts = unfold map RSA.In |
126 | val rules = List( | 122 | val rules = List( |
127 | Rule.create(roleRf, atomA, RSA.NotIn(varX)), | 123 | Rule.create(roleRf, atomA, RSA.NotIn(varX)), |
diff --git a/src/main/scala/uk/ac/ox/cs/rsacomb/RSAOntology.scala b/src/main/scala/uk/ac/ox/cs/rsacomb/RSAOntology.scala index 3527da5..c7b3bf0 100644 --- a/src/main/scala/uk/ac/ox/cs/rsacomb/RSAOntology.scala +++ b/src/main/scala/uk/ac/ox/cs/rsacomb/RSAOntology.scala | |||
@@ -459,7 +459,6 @@ class RSAOntology(val original: OWLOntology, val datafiles: File*) { | |||
459 | Logger.DEBUG | 459 | Logger.DEBUG |
460 | ) | 460 | ) |
461 | 461 | ||
462 | // TODO: the following functions needs testing | ||
463 | def confl( | 462 | def confl( |
464 | role: OWLObjectPropertyExpression | 463 | role: OWLObjectPropertyExpression |
465 | ): Set[OWLObjectPropertyExpression] = { | 464 | ): Set[OWLObjectPropertyExpression] = { |
@@ -655,7 +654,6 @@ class RSAOntology(val original: OWLOntology, val datafiles: File*) { | |||
655 | // We just need the TBox to find | 654 | // We just need the TBox to find |
656 | val terms = for { | 655 | val terms = for { |
657 | axiom1 <- tbox | 656 | axiom1 <- tbox |
658 | // TODO: is this an optimization or an error? | ||
659 | if axiom1.isT5 | 657 | if axiom1.isT5 |
660 | // We expect only one role coming out of a T5 axiom | 658 | // We expect only one role coming out of a T5 axiom |
661 | roleS <- axiom1.objectPropertyExpressionsInSignature | 659 | roleS <- axiom1.objectPropertyExpressionsInSignature |
diff --git a/src/main/scala/uk/ac/ox/cs/rsacomb/converter/RDFoxConverter.scala b/src/main/scala/uk/ac/ox/cs/rsacomb/converter/RDFoxConverter.scala index c9bed35..3fac46f 100644 --- a/src/main/scala/uk/ac/ox/cs/rsacomb/converter/RDFoxConverter.scala +++ b/src/main/scala/uk/ac/ox/cs/rsacomb/converter/RDFoxConverter.scala | |||
@@ -23,13 +23,6 @@ import uk.ac.ox.cs.rsacomb.util.{RSA, RDFoxUtil} | |||
23 | * @note the input axioms are assumed to be normalized. Trying to | 23 | * @note the input axioms are assumed to be normalized. Trying to |
24 | * convert non normalized axioms might result in undefined behavious. | 24 | * convert non normalized axioms might result in undefined behavious. |
25 | * We use the normalization defined in the main paper. | 25 | * We use the normalization defined in the main paper. |
26 | * | ||
27 | * @see [[https://github.com/KRR-Oxford/RSA-combined-approach GitHub repository]] | ||
28 | * for more information on the theoretical aspects of the system. | ||
29 | * | ||
30 | * @todo this is not ideal and it would be more sensible to prepend a | ||
31 | * normalization procedure that will prevent errors or unexpected | ||
32 | * results. | ||
33 | */ | 26 | */ |
34 | trait RDFoxConverter { | 27 | trait RDFoxConverter { |
35 | 28 | ||
@@ -358,7 +351,6 @@ trait RDFoxConverter { | |||
358 | */ | 351 | */ |
359 | case e: OWLDataSomeValuesFrom => { | 352 | case e: OWLDataSomeValuesFrom => { |
360 | val role = e.getProperty() | 353 | val role = e.getProperty() |
361 | // TODO: simplify this: | ||
362 | // Computes the result of rule skolemization. Depending on the used | 354 | // Computes the result of rule skolemization. Depending on the used |
363 | // technique it might involve the introduction of additional atoms, | 355 | // technique it might involve the introduction of additional atoms, |
364 | // and/or fresh constants and variables. | 356 | // and/or fresh constants and variables. |