-
Notifications
You must be signed in to change notification settings - Fork 4
FAQ
Welcome to the RuleML2TPTP FAQ! This page also serves as the supporting and flexible documentation characterized by brisk questions and answers. We think that this form is better for this project than a lengthy formal document. For reference links beyond, but related to, this project, see the entry page of the project.
The supported input source should be valid against this Datalog+ Deliberation RuleML 1.01 schema. <Retract> and <Data> are ignored and <Data> is warned about.
<Data> represents an "any-type" data model as an alternative to literal character strings. However in the TPTP language, there is no support for any-type data. Thus we ignore <Data> but give warnings about its occurrence in the source file.
One is to normalize the source RuleML file, and the other is for the real translation. RuleML allows abbreviated encoding (skipped edge tags and default attribute values) and some freedom in the ordering of elements. It would be much easier to do translation from normalized RuleML than from the original (un-normalized) source. Moreover, RuleML has provided normalizers in XSLT that we can utilize. The normalizer we use in this project is actually the one for a super set of Datalog+, however it goes well along with this project.
Because it is enough. The only Java class (the main class) in this project is to parse the command line arguments and translate the input as to the parsed options by invoking JAXP calls.
Why do you bother with Java code? Why not just call Saxon directly since it is executable, or use shell scripts to shorten the command typing?
Our translation has a normalization step as the pre-process. Calling Saxon directly is full of typing and memorizing. We tried shell scripts but they were platform- (or shell-) dependent. Then we found we preferred more to a platform-independent solution, so that we can avoid maintaining multiple sets of scripts for different platforms.
The Java code has inline comments and is quite straightforward. This should be enough for unerstanding it.
Try "java -jar ruleml2tptp.tar -h" at first.
Use option "-nt", which suppresses the real translation, so the result of normalization is written to the output. If the result of normalization is saved, for example, into a file, it can later be used as the source of the translation with option "-nn" (standing for "no normalization") to avoid doing the normalization again.
It is because the variables, constants and functors in the output do not conform to the TPTP language syntax. RuleML2TPTP can convert alphabetic case of the first letter, or single quote constants and functors from the RuleML input to make them valid in the output. However, sometimes they can not be made valid by such conversion when, for example, a variable includes characters other than letters, numbers and "_" (underscores). That is when the warnings are issued.
The warnings are directed to the standard error. When, for example, the output of the translation and the warnings are both to be printed on the screen, the warnings will be suppressed to avoid messing up the output. Redirecting the standard error or using option "-o" to output the translation to a file will bring up the warnings.
By default, comments in the source are converted into proper commenting syntax and are output. Use option "-g" with flag "v", that is, adding "-g v" into the command line, to ignore the comments.
Generally speaking, "%" (a percent sign) followed by a space will be inserted at the beginning of each line after the line has been trimmed clear of leading and trailing whitespaces. A trimmed comment line starting with "%" will not have a "%" and a space inserted again. Here is an example comment in XML:
<!--
An example comment:
% Indent
% A percent sign starts a comment line.
% %100 keep this
-->
It will be converted into the following:
% An example comment:
% Indent
% A percent sign starts a comment line.
% %100 keep this
Write that comment into two comments. Use "-c " to distinguish them. The pattern is a regular expression. Only the comments matching the pattern are selected and converted into proper commenting syntax to be output.
The regular expression is the same as that accepted by XPath functions. See XPath functions specification for the syntax.
See XPath functions specification for the flags. Basically "i" indicates case-insensitive mode, "s" indicates that "." (dot) can match the newline character, and "m" indicates multi-line mode where "^" (caret) and "$" (dollar sign) match the start and end of a line instead of the entire string. Flag "v" is specific to this program, indicating not to select the comments that match the pattern, but to select those that do not match. It is like "grep -v" on UNIX/Linux.
Because it is usually not a good idea to break a TPTP formula with comments. Only comments outside a TPTP formula, that is, at most as deep as the child nodes of <Assert> and <Query>, can be retained.
With this option, CRLF will be used to mark new lines in the output translation (like on Windows OS) instead of the default LF.
Yes. The java library file saxon.jar can be removed without re-compiling the project, and then the default JAXP implementation will be used. Alternatively, option "-t" can specify a third-party transformer factory class. Remember to put that factory class under the class path. Whichever implementation is about to use, make sure that the implementation supports XSLT 2.0 because this project uses a normalizer and a translator both in XSLT 2.0
See through the help printed by option "-h".