NRQL

nRQL (new Racer Query Language) is the ABox (for DL), RDF and OWL query language for RacerPro, pronounced: Nercle.

This sections refers to the user guide, pages 91ff.


 * an object is either an individual or a variable
 * variables: can only be bound to ABox individuals, they can not be bound to concrete domain attributes such as cardinal types
 * injective variables, e.g. "?x", can only be bound to an ABox individual which is not already bound.
 * ordinary variables, e.g. "$?x, need not be injective, an arbitrary mapping is find.
 * atoms are basic expressions in RQL
 * unary atoms reference one object, these are concept query atoms and retrieve the members of a concept
 * binary atoms reference two objects, these are role atoms, constraint atoms or SAME-AS query atoms
 * role query atoms: retrieve two individuals that relate through a specific property (or role)
 * constraint query atoms: meant to address the concrete domain part of a KB, i.e. using =, <>, ..., or constraint in the query
 * negation (Learn more about the strange behaviour of "neg" and "not" in NRQL Negation)
 * negation as failure (NAF): implemented with "neg", e.g. (retrieve (?x) (neg (?x place))) --> what is currently not know to be a place
 * true negation: implemented with "not", e.g. (retrieve (?x) (?x (not place))) --> what is definitely no place
 * properties (or here named roles)
 * inverse: (has-child :inverse has-parent :domain parent :range person)
 * symmetric: (friend-of :domain person :range person :inverse friend-of)
 * transitive: (located :domain place :range place :transitive t)
 * reset RacerPro
 * (full-reset)
 * (delete-all-tboxes) - before adding a new tbox
 * features are functional roles
 * NRQL-EQUAL-ROLE
 * attributes: must be declared in the signature (":attribute (integer age))
 * concrete domain attributes are considered as “typed” since they can either have fillers of type cardinal, integer, real, complex, or string. In addition to declaration in signature the following expression should be placed after the signature: "(define-concrete-domain-attribute age :type cardinal)"
 * Explicit and Implicit Role Fillers:
 * explicit - with role query atoms
 * implicit - with concept query atoms such as "some"
 * head projection operators to retrieve concrete domain objects


 * see example queries

=negation= This section includes a detailed example in order to specify a negated query:

knowledge base1
(in-knowledge-base friendship imti-friendship)

(signature :atomic-concepts (place person)	  :roles (lives-in)	   :individuals (fr hans udo de))

(related hans fr lives-in) (related udo de lives-in)

queries: (retrieve (?x) (?x de lives-in))
 * output: ((((?X UDO)))

(retrieve (?x) (?x ?y lives-in))
 * output: (((?X UDO)) ((?X HANS)))

(retrieve (?x) (?x de (not lives-in)))
 * output: NIL
 * expected: Hans (since he does not live in de)
 * but: correct since "not" only checks if a relationship cannot exist by definition,
 * however it is not specified that hans cannot also live in de

(retrieve (?x) (neg (?x de lives-in)))
 * output: (((?X FR)) ((?X DE)) ((?X HANS)) ((?X UDO)))
 * expected: all but udo (since this is currently not known)
 * seems as there is still not enough knowledge about udo or we are not using neg correctly
 * P.S. (you will see later that this is the case)

knowledge base2
(in-knowledge-base friendship imti-friendship)

(signature :atomic-concepts (place person)	  :roles (lives-in)	   :individuals (fr hans udo de))

(instance hans person) (instance udo person) (instance fr place) (instance de place)

(related hans fr lives-in) (related udo de lives-in)

queries: (retrieve (?x) (?x ?y lives-in)) (ohne full-reset)
 * output: (((?X FR)) ((?X HANS)) ((?X UDO)))

(retrieve (?x) (?x ?y lives-in))
 * output: ((?X HANS)) ((?X UDO)))

(retrieve (?x) (?x de lives-in))
 * output: ((?X UDO)))
 * expected (((UDO)))

(retrieve (?x) (neg (?x de lives-in)))
 * output: (((?X UDO)) ((?X DE)) ((?X HANS)) ((?X FR)))
 * expected: all but udo

(retrieve (?x ?y) (neg (?x ?y lives-in))) output: (((?X UDO) (?Y HANS)) ((?X UDO) (?Y FR)) ((?X DE) (?Y UDO)) ((?X DE) (?Y HANS)) ((?X DE) (?Y FR)) ((?X HANS) (?Y UDO)) ((?X HANS) (?Y DE)) ((?X FR) (?Y UDO)) ((?X FR) (?Y DE)) ((?X FR) (?Y HANS)))
 * neg gives you all possible combinations of the individuals that are not explicity specified in a lives-in relationsships.
 * therefore, all combinations but (((?X UDO) (?Y de))) and (((?X Hans) (?Y fr))) are given
 * (e.g. (((?X DE) (?Y DE))) is not possible since ?x ?y rather then $?x $?y is used)

(retrieve (?x) (neg (?x de lives-in))) output: (((?X UDO)) ((?X DE)) ((?X HANS)) ((?X FR)))
 * assumption: neg gives all possible combinations but the ones that are explicity specified in the kb
 * based on that all combinations are given that have a "de" as second filler
 * therefore all combination but (((?X UDO) (?Y de))) (since this is in the knowledge base)
 * and with the second filler de (since the query says so) should be given
 * (((?X DE) (?Y DE))) is possible since only one variable is used
 * however, "udo" appears - we think that should be the case
 * assumption: specifying a filler in within a negation prevents the deleting of all existing combinations in the kb
 * is this a bug? or do we still not get how neg is working

(retrieve (?y) (and  (?y de lives-in)(= ?y udo)))
 * output: (((?Y UDO)))
 * okay

(retrieve (?y) (and  (= ?y udo) (neg (?y de lives-in))))
 * output: (((?Y UDO)))
 * !!!not okay; we thought that neg does not give the existing entries from the kb
 * my conclusion, we cannot use the filler in within the negation, rather see below...

(retrieve (?y) (and  (= ?y fr) (neg (?y de lives-in))))
 * output: (((?Y FR)))
 * okay

(retrieve (?x ?y) (and  (neg (?x ?y lives-in))  (= ?y de)))
 * output: (((?X HANS) (?Y DE)) ((?X FR) (?Y DE)))
 * this is better, instead of using the filler in within the negation, we use a constraint afterwards,
 * which specified that the second filler mustn't be "de"

(retrieve (?x ?y) (and  (neg (?x ?y lives-in))  (= ?y de) (?x person)))
 * output: (((?X HANS) (?Y DE)))
 * in order to get rid of all things that are no persons, we add another constraint
 * this gives all persons that do not live in "de"

knowledge base3
(in-knowledge-base friendship imti-friendship)

(signature :atomic-concepts (place person)	  :roles (lives-in is-located)	  :individuals (fr hans udo de))

(instance hans person) (instance udo person) (instance fr place) (instance de place) (instance bremen place) (instance iub place)

(related hans fr lives-in) (related udo de lives-in)

(related iub bremen is-located) (related bremen de is-located) (related paris fr is-located)

queries: (retrieve (?x) (and  (neg (?x ?y is-located)) (= ?y de) (?x place)))
 * output: (((?X FR)) ((?X IUB)))
 * okay, since transitivity hasn't been specified

knowledge base4
(in-knowledge-base friendship imti-friendship)

(signature :atomic-concepts (place person)	  :roles (lives-in (is-located :transitive t))	  :individuals (fr hans udo de))

(instance hans person) (instance udo person) (instance fr place) (instance de place) (instance bremen place) (instance iub place)

(related hans fr lives-in) (related udo de lives-in)

(related iub bremen is-located) (related bremen de is-located) (related paris fr is-located)

queries: (retrieve (?x)  (?x ?y is-located))
 * output: (((?X PARIS)) ((?X BREMEN)) ((?X IUB)))
 * okay - de and fr are not given since they are not specified as first filler in a is-located relationship

(retrieve (?x)  (?x de is-located))
 * output: (((?X BREMEN)) ((?X IUB)))
 * IUB is given since it transitive relation to de

(retrieve (?x) (and (?x ?y is-located)(neg (?y ?z is-located)) (= ?z de)))
 * output: (((?X Paris)))
 * the solution for getting all place not in de
 * this is totally wrong!!!

knowledge base5
(in-knowledge-base friendship imti-friendship)

(signature :atomic-concepts (place person)	  :roles (lives-in (is-located :transitive t))	  :individuals (fr hans udo de))

(instance hans person) (instance udo person) (instance fr place) (instance de place) (instance bremen place) (instance iub place)

(related hans fr lives-in) (related udo de lives-in)

(related iub bremen is-located) (related bremen de is-located) (related paris fr is-located) (related notreDame paris is-located)

queries: (retrieve (?x) (and (?x ?y is-located)(neg (?y ?z is-located)) (= ?z de)))
 * output: (((?X NOTREDAME)) ((?X PARIS)))

(retrieve (?x) (and (?x ?y located)(neg (?y ?z located)) (= ?z fr)))
 * output: (((?X BERLIN)) ((?X BREMEN)) ((?X IUB)))

(retrieve (?x ?y ?z) (and (?x ?y is-located)(neg (?y ?z is-located)) (= ?z fr)))
 * what exactly happens:
 * output: (((?X BERLIN)(?Y DE)(?Z FR)) ((?X BREMEN)(?Y DE)(?Z FR)) ((?X IUB)(?Y DE)(?Z FR)) ((?X IUB)(?Y BREMEN)(?Z FR)))
 * and between:
 * 1. (((?X PARIS) (?Y FR)) ((?X BERLIN) (?Y DE)) ((?X BREMEN) (?Y DE)) ((?X IUB) (?Y DE)) ((?X IUB) (?Y BREMEN)))
 * 2. (((?Y BERLIN) (?Z FR))((?Y BREMEN) (?Z FR)) ((?Y DE) (?Z FR)) ((?Y IUB) (?Z FR)))

(retrieve (?x ?y ?z) (and (?x ?y is-located) (neg (?y ?z is-located)) (= ?z iub)))
 * output: (((?X NOTREDAME)(?Y FR)(?Z IUB)) ((?X NOTREDAME)(?Y PARIS)(?Z IUB)) ((?X PARIS)(?Y FR)(?Z IUB)) ((?X BREMEN)(?Y DE)(?Z IUB)))
 * okay

(retrieve (?x ?y ?z) (and (?x ?y is-located) (neg (?y ?z is-located)) (= ?z bremen)))
 * output: (((?X NOTREDAME)(?Y FR)(?Z BREMEN)) ((?X NOTREDAME)(?Y PARIS)(?Z BREMEN)) ((?X PARIS)(?Y FR)(?Z BREMEN))
 * ((?X IUB)(?Y DE)(?Z BREMEN)))
 * not okay: IUB should not be given; but looking at the query this solution is correct -> query is incorrect
 * we need to indicate the order of the places (problem is the transitivity of IUB)

(retrieve (?x ?y ?z) (and (?x ?y is-located) (neg (?y ?z is-located)) (neg (?z ?y is-located)) (= ?z bremen)))
 * output: (((?X NOTREDAME)(?Y FR)(?Z BREMEN)) ((?X NOTREDAME)(?Y PARIS)(?Z BREMEN)) ((?X PARIS)(?Y FR)(?Z BREMEN)))
 * not okay: gives everything that is not located in Bremen or that is not located in the same places as bremen

knowledge base6
(in-knowledge-base friendship imti-friendship)

(signature :atomic-concepts (place person)	  :roles (lives-in (is-located :transitive t))	  :individuals (fr hans udo de))

(instance hans person) (instance udo person) (instance fr place) (instance de place) (instance bremen place) (instance iub place)

(related hans fr lives-in) (related udo de lives-in)

(related de europe is-located) (related bremen de is-located) (related iub bremen is-located) (related eecs iub is-located)

(related fr europe is-located) (related paris fr is-located) (related notreDame paris is-located)

queries: (retrieve (?x ?y ?z) (and (?x ?y is-located) (neg (?y ?z is-located)) (= ?z europe)))
 * output: NIL

(retrieve (?x) (and (?x ?y is-located) (neg (?y ?z is-located)) (neg (?z ?y is-located)) (= ?z iub)))
 * output: ((?X NOTREDAME)(?X PARIS))
 * not okay, since "bremen", "de", "fr", ("europe") should be given
 * what happens: and between
 * 1. (((?X NOTREDAME)(?Y EUROPE)) ((?X NOTREDAME)(?Y FR)) ((?X NOTREDAME)(?Y PARIS)) ((?X PARIS)(?Y EUROPE))
 * ((?X PARIS)(?Y FR)) ((?X FR)(?Y EUROPE)) ((?X EECS)(?Y EUROPE)) ((?X EECS)(?Y DE)) ((?X EECS)(?Y BREMEN))
 * ((?X EECS)(?Y IUB)) ((?X IUB)(?Y EUROPE)) ((?X IUB)(?Y DE)) ((?X IUB)(?Y BREMEN)) ((?X BREMEN)(?Y EUROPE))
 * ((?X BREMEN)(?Y DE)) ((?X DE)(?Y EUROPE)))
 * can you ignore the transitivity???
 * 2. (((?Y EUROPE)(?Z IUB)) ((?Y FR)(?Z IUB)) ((?Y PARIS)(?Z IUB))((?Y DE)(?Z IUB)) ((?Y BREMEN)(?Z IUB)))
 * 3. (((?Z IUB)(?Y FR))((?Z IUB)(?Y PARIS)))
 * we want to specify everything that is "not located in IUB or (if directly located) not located in a place in which IUB is located)
 * this would be (((?X NOTREDAME)(?Y EUROPE)) ((?X NOTREDAME)(?Y FR)) ((?X NOTREDAME)(?Y PARIS)) ((?X PARIS)(?Y EUROPE))
 * ((?X PARIS)(?Y FR)) ((?X FR)(?Y EUROPE)) ((?X BREMEN)(?Y EUROPE)) ((?X BREMEN)(?Y DE)) ((?X DE)(?Y EUROPE)))
 * but not: (((?X EECS)(?Y EUROPE)) ((?X EECS)(?Y DE)) ((?X EECS)(?Y BREMEN)) ((?X EECS)(?Y IUB)) ((?X IUB)(?Y EUROPE))
 * ((?X IUB)(?Y DE)) ((?X IUB)(?Y BREMEN)))

Knowledge base7
(in-knowledge-base friendship imti-friendship)

(signature :atomic-concepts (place person)	  :roles (lives-in (is-located :transitive t))	  :individuals (hans udo europe de fr bremen iub eecs notreDame paris))

(instance hans person) (instance udo person) (instance fr place) (instance de place) (instance bremen place) (instance iub place) (instance eecs place) (instance notreDame place) (instance europe place) (instance paris place)

(related hans fr lives-in) (related udo de lives-in)

(related de europe is-located) (related bremen de is-located) (related iub bremen is-located) (related eecs iub is-located)

(related fr europe is-located) (related paris fr is-located) (related notreDame paris is-located)

queries: (retrieve (?x ?y) (and (?x place) (neg (?x ?y is-located))(= ?y iub)))
 * output: (((?X FR)) ((?X DE)) ((?X BREMEN)) ((?X NOTREDAME)) ((?X EUROPE)) ((?X PARIS)))
 * correct

(retrieve (?x) (and (?x place) (neg (?x iub is-located))))
 * output: (((?X NOTREDAME)) ((?X PARIS)) ((?X FR)) ((?X EUROPE)) ((?X EECS)) ((?X IUB)) ((?X BREMEN)) ((?X DE)))
 * this is what we do not understand - why can "iub" not be specified inwithin the neg-part

--Christine 14:03, 20 November 2006 (CET)