Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
doc:defining_computables [2014/11/26 20:48] – [Caveats] admindoc:defining_computables [2014/11/26 21:00] (current) – [SQL computables] admin
Line 29: Line 29:
 </code> </code>
 The //rdf_triple// predicate combines the results of different inference methods: It first searches for sub-properties of the current property, and for each of them, first calls //rdf_has// for reading information asserted in the knowledge base directly, then calls all computable triples defined for any subproperty, and finally creates a hook to which other modules can attach. The code for managing the computables is contained in the module //rdfs_computable.pl// in //knowrob_common//. The //rdf_triple// predicate combines the results of different inference methods: It first searches for sub-properties of the current property, and for each of them, first calls //rdf_has// for reading information asserted in the knowledge base directly, then calls all computable triples defined for any subproperty, and finally creates a hook to which other modules can attach. The code for managing the computables is contained in the module //rdfs_computable.pl// in //knowrob_common//.
- 
-===== Debugging ===== 
- 
-When something does not work, check the following. Most likely, there is a minor inconsistency in the OWL names that makes the whole process break. 
-  * is the right property being computed? knowrob:objectActedOn is something else than ias:objectActedOn 
-  * is there a typo anywhere in the namespaces or base URLs? 
-  * check if there is a hash sign # between the URL and the property name (if using XML entities, check if the hash is either part of the entity or written where the entity is being used in the code) 
-  * debug with the following calls and step through to check that the right computable is being found, that the right query is sent, or that your predicate performs the right computations. 
-<code> 
- guitracer, spy(yourpredicate), rdf_triple(knowrob:pred, Subj, Obj). for Prolog computables 
- guitracer, spy(rdfs_computable_sql_triple), rdf_triple(knowrob:pred, Subj, Obj). for SQL computables 
-</code> 
- 
- 
-Some general remarks: 
-  * Computables should be defined in their own module; the computables for temporal relations (before, after, during etc), for example, are defined in the module //comp_temporal//. This helps to resolve conflicts if there are different computables for a relation (e.g. one observes and another one predicts a relation). 
-  * The &bla; identifiers are XML entities that are replaced with the string specified at the beginning of the file when the file is being loaded. They are useful for making the code a bit shorter and more readable, and also for ensuring consistency. 
  
  
  
 ===== Prolog computables ===== ===== Prolog computables =====
-  * Prolog computables, which evaluate a binary Prolog predicate that computes an OWL relation+Prolog computables computes an OWL relation by evaluating a binary Prolog predicate.
  
  
  
-===== Prolog properties =====+==== Prolog properties ====
  
-For Prolog properties, we will have a look at the knowrob:after relation between two temporal events. It assumed to be rather general, thus defined in knowrob.owland computed using a Prolog computable. First, the property is defined: +For Prolog properties, we will have a look at the knowrob:after relation between two temporal events. As a rather general propertyit is defined in knowrob.owl and can be computed using a Prolog computable. First, the property is defined: 
-<code>+<code xml>
   <owl:ObjectProperty rdf:about="#after">   <owl:ObjectProperty rdf:about="#after">
       <rdfs:range rdf:resource="#TimePoint"/>       <rdfs:range rdf:resource="#TimePoint"/>
Line 65: Line 48:
 </code> </code>
  
-Then, the computable that is attached to this property needs to be specified+Then, the property is linked to the Prolog predicate //comp_after// for computing it
-<code>+<code xml>
   <computable:PrologProperty rdf:about="#computeAfter">   <computable:PrologProperty rdf:about="#computeAfter">
 +      <computable:target rdf:resource="#after"/>
       <computable:command rdf:datatype="&xsd;string">comp_after</computable:command>       <computable:command rdf:datatype="&xsd;string">comp_after</computable:command>
-      <computable:cache rdf:datatype="&xsd;string">dontCache</computable:cache> +      [...]
-      <computable:visible rdf:datatype="&xsd;string">unvisible</computable:visible> +
-      <computable:target rdf:resource="#after"/>+
   </computable:PrologProperty>   </computable:PrologProperty>
 </code> </code>
  
-Note that the target is described as in SQL properties, but instead of covering the different cases of bound/free variables with different SQL queries, we only specify one Prolog predicate (comp_after) that is supposed to handle them correctly. comp_after needs to be specified somewhere where it is available once knowrob.owl is loaded, which, in our case, is the gram_base.pl.  +Note that the target is described as a binary Prolog predicate (comp_after) that is supposed to handle the different cases of subject and/or object being bound//comp_after// needs to be specified somewhere where it is available once knowrob.owl is loaded, which, in our case, is the module //comp_temporal//.  
-<code>+<code prolog>
   % after(TimePoint, TimePoint)   % after(TimePoint, TimePoint)
   comp_after(Pre, After) :-   comp_after(Pre, After) :-
Line 86: Line 68:
 </code> </code>
  
-This predicate first checks if the subject and property have the correct types, then transforms the time points into numerical values using term_to_atom, and finally compares them to check if Pre is really earlier than After. +This predicate first checks if the subject and property have the correct types, then transforms the time points into numerical values using //term_to_atom//, and finally compares them to check if //Pre// is smaller than //After//
-  * Prolog computables can do much more than just compare values: Using the Java interface JPL, we included the ehow.com plan import as a Prolog computable datatype property which links Strings like "set a table" to plan specifications in OWL. The same technique was used to interface Prolog to ROS and read object poses from the jlo service. Rule knowledge (for unary or binary predicates) can be encoded in Prolog computables, when the body of the rule is checked in the computable.+  * Prolog computables can do more than comparing values: Using the Java interface JPL, we included the ehow.com plan import as a Prolog computable datatype property which links Strings like "set a table" to plan specifications in OWL. The same technique was used to interface Prolog to ROS and read object poses. Rule knowledge (for unary or binary predicates) can be encoded in Prolog computables if the body of the rule is checked inside the computable.
   * When trying to use rdf_assert inside a Prolog computable, you are likely to get an error "operation would deadlock". This happens when trying to modify the rdf database while rdf choicepoints are still open, e.g. not all solutions to all rdf_has have been found. Workarounds are sometimes possible by packing rdf_has inside a findall and by iterating over the results with member, or, if just one solution shall be found, by using the cut operator '!'.   * When trying to use rdf_assert inside a Prolog computable, you are likely to get an error "operation would deadlock". This happens when trying to modify the rdf database while rdf choicepoints are still open, e.g. not all solutions to all rdf_has have been found. Workarounds are sometimes possible by packing rdf_has inside a findall and by iterating over the results with member, or, if just one solution shall be found, by using the cut operator '!'.
  
-===== Prolog classes =====+==== Prolog classes ====
  
-The definition of computable prolog classes is similar to the preceding ones, you simply need to describe the class (here: DrinkingMug) and a binary predicate (here: comp_objectsOnTable(Inst, Class) ) that computes either instances of a class of the class of an instance. +The definition of computable prolog classes is similar to Prolog properties. You simply need to describe the class (here: DrinkingMug) and a binary predicate (here: comp_objectsOnTable(Inst, Class) ) that computes either instances of a class of the class of an instance. 
-<code>+<code xml>
   <computable:PrologClass rdf:about="#computeObjectOnTable">   <computable:PrologClass rdf:about="#computeObjectOnTable">
     <computable:command rdf:datatype="&xsd;string">comp_objectsOnTable</computable:command>     <computable:command rdf:datatype="&xsd;string">comp_objectsOnTable</computable:command>
Line 103: Line 85:
  
  
-====== SQL computables =====+===== SQL computables =====
-SQL computables, which use SQL queries for reading external data, and+
  
 +SQL computables used SQL queries for reading external data. They are currently deactivated, but the code is still available in the rdfs_computable module. You need to make sure that [[http://swi-prolog.org/pldoc/doc_for?object=section%28%27packages/odbc.html%27%29|ODBC is set up correctly]]. **The following paragraphs have been kept for archival reasons, but SQL computables are currently not functional.**
  
-===== SQL properties =====+==== SQL properties ====
  
 As mentioned before, the first step is to define the target to be computed. In this example, which can be found in ias_gram_human.owl, we choose to compute a property ias_human:xCoord, which is a specialisation of knowrob:xCoord (which is defined with the domain SpatialThing) for Point2D. As mentioned before, the first step is to define the target to be computed. In this example, which can be found in ias_gram_human.owl, we choose to compute a property ias_human:xCoord, which is a specialisation of knowrob:xCoord (which is defined with the domain SpatialThing) for Point2D.
Line 149: Line 131:
 </code> </code>
  
-===== SQL classes =====+==== SQL classes ====
  
 The definition of computable SQL classes is rather similar to properties and will only be shortly explained. Obviously, the target class has to exist for the method to work. computeReaching reads human motion frames labeled as 'Reaching' from the database: The definition of computable SQL classes is rather similar to properties and will only be shortly explained. Obviously, the target class has to exist for the method to work. computeReaching reads human motion frames labeled as 'Reaching' from the database:
Line 169: Line 151:
 </code> </code>
 Here, we do not have the frame/value scheme, but rather one command for creating instances (command) and one for checking if an instance belongs to the respective class (testCommand). Here, we do not have the frame/value scheme, but rather one command for creating instances (command) and one for checking if an instance belongs to the respective class (testCommand).
 +
 +
 +===== Debugging =====
 +
 +When something does not work, check the following. Most likely, there is a minor inconsistency in the OWL names that makes the whole process break.
 +  * is the right property being computed? knowrob:objectActedOn is something else than ias:objectActedOn
 +  * is there a typo anywhere in the namespaces or base URLs?
 +  * check if there is a hash sign # between the URL and the property name (if using XML entities, check if the hash is either part of the entity or written where the entity is being used in the code)
 +  * debug with the following calls and step through to check that the right computable is being found, that the right query is sent, or that your predicate performs the right computations.
 +<code>
 + guitracer, spy(yourpredicate), rdf_triple(knowrob:pred, Subj, Obj). for Prolog computables
 + guitracer, spy(rdfs_computable_sql_triple), rdf_triple(knowrob:pred, Subj, Obj). for SQL computables
 +</code>
 +
 +
 +Some general remarks:
 +  * Computables should be defined in their own module; the computables for temporal relations (before, after, during etc), for example, are defined in the module //comp_temporal//. This helps to resolve conflicts if there are different computables for a relation (e.g. one observes and another one predicts a relation).
 +  * The &bla; identifiers are XML entities that are replaced with the string specified at the beginning of the file when the file is being loaded. They are useful for making the code a bit shorter and more readable, and also for ensuring consistency.
 +