Help:Extension:OttrParser

Note: When you edit this page, you agree to release your contribution under the CC0. See Public Domain Help Pages for more info.

This extension provides a parsing of OTTR statements and a suitable generation of wikicode that implements an equivalent behavior for such statement in the MediaWiki. E.g., produce RDF triples based on semantic grouped templates for a consistent and simple instantiation of triple based information.

The Extension Page: Extension:OttrParser

General usage of the extension

Parse and replace OTTR text with wikicode are done via one of the following OTTR calls.

Important: on every page there should only be ONE OTTR call regardless of the variant of the call!

OTTR tag

Generating the wikicode for any OTTR code, the extension provides a html tag, that replaces itself while parsing with the wikicode adding the equivalent functionality.

<ottr> ... </ottr>

The advantage of the html tag is that you can use the pipe character | and equal sign = inside the tags (in contrast to the parser function syntax). The disadvantage is the loss of the functionality of substitution thus the prevention of repeating extension/python calls.

Form attribute

When the attribute form is not empty, the extension does not add the Debug and Display-Wikicode part of the generated code in the output. This is mostly desired in form calls.

<ottr form=True> ... </ottr>

OTTR Function

For Help:Substitution#Multilevel_substitution, the extension provides a parser function for templates.

Example
Include something like this in your Template page:

{{safesubst:#ottrFunction: ... }}

The extension writes the safesubst call in the page, but surrounded with HTML-Comment characters (). For re-running the parser delete all the generated code, except the safesubst call.

Appearance options

The extension adds to the generated code some highlighting and hints of the generated data and code. The display behavior of the individual parts can be global turned on and off with a switch from 0 to 1 and vis versa in the corresponding templates.

Template:ottr:DisplayOttr

Display the formulated OTTR call outside the editing mode can be useful on the rendered page. Both for instances and template definitions.

Example Appearance:

OTTR-Definition:

 ex:Template1 [ ?arg1, ?arg2, ?arg3] :: {
     ottr:Triple (?arg1, ex:testPredicate, ex:testObject) ,
     ottr:Triple (ex:testSubject, ?arg2, ex:testObject) ,
     ottr:Triple (ex:testSubject, ex:testPredicate, ?arg3)
 } .

Template:ottr:DisplayFormHelp

For easy creating forms and instances, the extension adds a text part to each template, that let the user use them. The default page for a form is the same name as the template, but in the Form namespace. With the InputBox extension a button links to the new page with the automated content that fits to the defined template. If the default page for a form exists, the button disappears and a link to the generated form appears, that expects the name of a page for new instances.

Example Appearance of a button to create a form page:

Form Info:
The OTTR-Extension comes with an automated form creation, which simplifies the generation of instances of a template via input fields:

Example Appearance of a link to create an instance of the template:

Form Info:
The OTTR Extension comes with an automated form creation, which simplifies the generation of instances of a template via input fields:

Create instance with form

Template:ottr:DebugOnOFF

The extension provides some (debug) information about generated instances. This includes the number of initialised triples, number of different used IRIs (an indication of the connectedness of the page), the max depth of OTTR-template calls and a list of all used OTTR-Templates and their number of calls.

Example Appearance:

Debug Info:

Number Init Triples: 3

Number Used IRIs: 6

Max Depth: 2

Used Templates:

- ex:Template1: 1
- ottr:Triple: 3

Template:ottr:AllAnnotationsOnOff

The feature annotations from the OTTR-language are relevant for additional information about the template. So the first called template should get called. For ignoring such limitation and call every annotation of all called templates turn this ON. The extension uses the annotation also for specifying layout templates for a template (See here).

Template:ottr:DisplayTriplesOnOff

Include an inline ask query about the triples defined on this page. Needs sometimes more refreshes for displaying the table.

Example Appearance:

Generated Triples: (Needs sometimes 2x refreshes)

Subject Predicate Object
ExampleInstances:Template1 Ex:TestPara1 Ex:testPredicate Ex:testObject
ExampleInstances:Template1 Ex:testSubject Ex:testPredicate Ex:TestPara3
ExampleInstances:Template1 Ex:testSubject Ex:TestPara2 Ex:testObject

Template:ottr:DisplayCode

Display the generated Wikicode for the instances or template on a page.

Example Appearance:

Wikicode:

{{#ifexpr: {{ottr:DebugOnOFF}}|{{#vardefine:ottr_triple_count|0}}{{#vardefine:ottr_used_iris|}}{{#vardefine:ottr_max_depth|0}}{{#vardefine:ottr_used_templates|}}}}{{ex:Template1|ex:TestPara1|ex:TestPara2|ex:TestPara3|ottr_arg_type_1=ottr:IRI§rdfs:resource|ottr_arg_type_2=ottr:IRI§rdfs:resource|ottr_arg_type_3=ottr:IRI§rdfs:resource|call_occurrence={{FULLPAGENAME}}_0|call_depth=1}}{{#ifexpr: {{ottr:DebugOnOFF}}|<b>Debug Info:</b>
* <i>Number Init Triples:</i> <b>{{#var:ottr_triple_count}}</b>
* <i>Number Used IRIs:</i> <b>{{#arraydefine:ottr_used_iris_set|{{#var: ottr_used_iris}}|,}}{{#arrayunique:ottr_used_iris_set}}{{#arraysize:ottr_used_iris_set}}{{#arrayreset:ottr_used_iris_set}}</b>
* <i>Max Depth:</i> <b>{{#var:ottr_max_depth}}</b>
* <i>Used Templates:</i>
{{#arraydefine:ottr_used_templates_set|{{#var:ottr_used_templates}}|,}}{{#arrayunique:ottr_used_templates_set}}{{#loop: ottr_used_templates_idx|0|{{#arraysize:ottr_used_templates_set}}|{{#ifexpr: {{#var:ottr_used_templates_idx}}|-|:-}} {{#arrayindex:ottr_used_templates_set|{{#var:ottr_used_templates_idx}}}}:  <b>{{#count:{{#var:ottr_used_templates}}|{{#arrayindex:ottr_used_templates_set|{{#var:ottr_used_templates_idx}}}},}}</b><br/>}}{{#arrayreset:ottr_used_templates_set}}
<nowiki/>
}}{{#ifexpr: {{ottr:DisplayTriplesOnOff}}|{{ottr:AskForTriples}}}}

Prefixes and Comments

The extension uses prefixes from RDFs as namespaces of the wiki, e.g. the page of the IRI xsd:integer lies in the xsd-namespace. Mapping now the prefix to the full IRI is done with a prefix expression, that contains the mapping information from prefix to the expanded URL. Because of organizational and clarity reasons, the extension wants to collect all Prefix information on one page. So, every occurrence of a prefix definition outside this particular page will give a warning, if the prefix is not defined on the prefix page already.

The default page for all prefixes is ottr:ottrPrefixes.

Syntax

The OTTR-syntax for prefixes is like the one in the turtle language. It starts with @prefix and states then the prefix and the URL (in < and > signs) separated by a colon. It ends (like every OTTR statement) with a dot, e.g.

@prefix xsd: <w3 link here> .

Appearance

The displaying result depends on different preconditions:

The statement is on the prefix page:

Prefix: xsd: <w3 link here>

The statement is on another page and the prefix is not defined on the prefix page:

Warning: Prefix pt2 is not defined on page Ottr:OttrPrefixes!

The statement is already on the prefix page:

The prefix statement has no effect and no appearance.

Side Effects

On the Prefix page it produces also a subobject with the properties:

IRI: The complete URL without the < and >.
Namespace: The prefix name.
Subobject-category: OTTR-Prefix, for querying.

The Warning message produces like every error and warning box also a subobject of the subobject-category OTTR-Error, containing the message and a simple error code.

Comments

Text declared as a comment is ignored by the parser.

The OTTR-syntax provides single- (# ...) and multi-line (/*** ... ***/) comments.

Template Definition

Writing an OTTR-Template, that can call other OTTR-Templates and produce at the end Triples, is one of the main usage parts of the extension. An OTTR-Template consists of a signature, containing the name of the template and the argument definitions, and the template hull. A template can have arguments with different options (parameter modifiers) and also a type restriction per argument is possible. Inside the template hull it states instance calls of other templates. An exception is a base template that maps it three input arguments to a triple representation (subject, predicate and object). In the OTTR-Language arguments are only passed via their position and not via a name reference, so the names of the arguments are only important for the usage of them inside the template.

An OTTR-Template must be on a page that is inside the Template-namespace and only one template per page is allowed. Other instances outside the template definition are ignored.

Syntax

The signature of a template consists of the template name (that must be equal to the page name, without the Template-Namspace) and the parameter declaration (arguments in the following). The arguments are inside square brackets [ ]and are separated by commas ,. The name of the argument starts with a ?. For additional parameter/argument features see the table below. The signature and the template hull is connected with double colons ::. The list of template calls inside the hull are surrounded with curly brackets { } and separated by commas ,. Only the Base template is declared via the template hull: BASE. Template calls inside a template are like the instantiation outside a template only with the difference, that there are arguments from a template signature allowed. The statement ends with a dot ..

An example of a BASE Template and a template with 2 inner template calls:

ottr:Triple[?subject, ?predicate, ?object] :: BASE .

ex:Template_1[?arg1, ?arg2, ?arg3] :: {
  ottr:Triple(?arg1, ex:PredictateTest1, ?arg2),
  ottr:Triple(?arg1, ex:PredictateTest2, ?arg3)
} .

Appearance

Apart from warnings, errors and OTTR display hints and information, a template definition does not produce any visible text. Display the input variables or other stuff use Layout Annotations, see here

Side Effects

The extension inserts wiki code such that a call from the template page with another OTTR statement produce the from the template declared triples and other template calls. It should check modifiers and restrictions and the execution of the inner template definition should depend on the result of the checks.

Signature Features

OTTR-Feature	Description	Example Code
Optional Argument	A template can accept arguments with a none-value, if the argument is declared as optional with an extra question mark `?`. A template will then instantiate its template calls. If an argument gets passed a none-value without the optional modifier the template will produce no template calls and no warnings or errors. The parameter options (optional and non blank) are before the template name and before a type restriction. An argument can have both, an optional and a non blank modifier.	ex:Template[? ?arg1, ?arg2, ? xsd:integer ?arg3] The first and third arguments are optional, the second not. The third has also a type restriction.
Default Value	In the case, that the argument is none, the template can declare a default value that is used instead. It should be consistent with the type restriction. It's written with an equal sign `=` that separated the argument name and the default value.	ex:Template[? ?arg1, ?arg2 = ex:info, ? xsd:integer ?arg3 = 0] The second and third parameter/argument have a default value (the IRI `ex:info` and the number `0`). In the implementation an optional modifier is not needed for a default value.
Non Blank Argument	A template cannot accept arguments that are blank nodes for different parameters, this is done with the non-blank modifier. It is an exclamation mark `!`. In contrast to the optional modifier, it produces an error if a blank node is passed to the template and does not produce its template instantiations.	ex:Template[?! ?arg1, ! ?arg2, ? xsd:integer ?arg3] The first argument is declared as non-blank and optional. The second has only the non-blank modifier.
Type Restriction	Restricting an input to a specific type is done via a type restriction between parameter modifiers and the argument name. It is possible to check an argument for simple type match of OTTR inputs, including check for string (rdfliteral), numbers (integers and floats), boolean and IRIs. Also, a check the nested Lists is possible. A type declaration of a rdfliteral/string (via `^^`) is also checked. For inferencing an IRI relationship of a rdfs:SubClassOf and rdf:type is more complex and only produce warnings (this includes a LUB (least upper bound) check), see Type Inferencing for establishing such relationship inside the wiki. The IRIs for the different simple types are: integer: `xsd:integer` (it also gets the additional types `xsd:float` and `rdfs:resource`) float: `xsd:float` (it also gets the additional type `rdfs:resource`) boolean: `xsd:boolean` (it also gets the additional type `rdfs:resource`) IRI: `ottr:IRI` (it also gets the additional type `rdfs:resource`) Request a List or nested lists the OTTR-syntax provides the `List` word with the requested type of the elements of the list inside `< >`. Also request Not-Empty Lists with `NEList` And also, the LUB restriction, such that the input has to be a direct instance of a type without nested subclass behavior.	ex:Template[?! List<xsd:float> ?arg1, ! ?arg2, ? xsd:integer ?arg3] The first argument restricts its input to lists of numbers and the third to integers. ex:Template[?! NEList<xsd:date> ?arg1, ! ?arg2, ottr:IRI ?arg3] Here the first argument tries to get a not empty list of dates. Such inputs could be `"MyDataInMyDateFormatHere"^^xsd:date`. The template throws an error if the input of the third argument is not an IRI (except if a string has an ottr:IRI-type declaration).^
Annotations	With annotations OTTR calls other templates that should not belong to the normal rdf graph. Annotations are added to the signature after the parameter/argument list and are separated with commas `,`. Each template annotation call starts with `@@`, but otherwise resemble to normal template calls/instantiations. The templates specified inside an annotation are called if the defined template is called not inside a template (so only normal instances). The extension uses annotations for specifying a layout of a template. If the template of an annotation is inside the Layout namespace, this template call is then passed additional arguments, that contain information about the input arguments of the defined template, see here for more information.	ex:Template[?! ?arg1, ! ?arg2, ? xsd:integer ?arg3] @@ex:AnnoTemplate(ex:Template, 2, 3), @@ex:AnnoTemplate2(ex:Template, "argument string") The `ex:Template` has two annoations template calls. ex:Template2[?! ?arg1, ! ?arg2, ? xsd:integer ?arg3] @@Layout:MyLayoutTemplate(ex:Template, 2, 3) The `ex:Template2` has an annotation template that lies in the Layout namespace.

Instantiation

Instantiation of OTTR-Templates is the other main usage of the OTTR-language. A template instantiation is written on a normal page. But the syntax is the same for template calls inside templates and annotations.

Syntax

The template name to instantiate and the arguments surrounded by brackets ( ), separated by commas ,, and dot is needed for an instantiation. There are additional features for an instance described below, e.g. lists and list expands, none and blank arguments.

ex:Template(ex:test, 4, "testString"@en) .

Appearance

Besides debug information, hints and information, instances do not produce visible text by default. Added Layout Templates to a template can show the input of the template.

For instances some type depending on templates can produce some information requests to the user to establish the type dependencies. See here.

Side Effects

The idea of instances is to generate the triples from the called templates. So, the results are subobjects with the subobject-category OTTR-Triple. If errors or warnings occur also the categories OTTR-Error.

{{#subobject: |subject={{{1}}} |predicate={{{2}}} |object={{{3}}} |subobject-category=OTTR-Triple }}

List Features

OTTR comes with the functionality to handle a set of arguments in lists.

Define a List

Defining a list as an argument or as a default value is quite simple. Elements are surrounded by brackets ( ) and separated by commas ,. A list can contain any normal input of the underlying position.

(1,2,3,4)

(ex:elem1, ex:elem2, ex:elem3)

(4, ex:elem3, 5.6, false, "test")

((1,1),(1,2),(1,3))

List Expand

To use defined lists in a template, the OTTR-language provides an expand command. In front of a passed list argument, the list expand symbol (two pluses) ++ is needed for an expand. Furthermore, a list expander command is needed in front of the instance (separated by a vertical bar/pipe |). The three different list expander and their behavior are described in the table below. For every element the code produces an independent fold-out of the described template (repeat the template instantiation for each expand). Writing the list expand symbol inside a template hull, in front of an argument name is also valid, if the argument is a list. The empty list is ().

zipMin | ex:Template(++(1,2,3,4), ("a number","a symbol"), ++("one", "two", "three", "four")).

The first and third argument is expanded. The second argument is passed as a normal argument to every instance in the fold-out. This example would produce 4 instances of the ex:Template-template, e.g.

ex:Template(1, ("a number","a symbol"), "one").
ex:Template(2, ("a number","a symbol"), "two").
ex:Template(3, ("a number","a symbol"), "three").
ex:Template(4, ("a number","a symbol"), "four").

The different list expander only produces different behavior, if there are more than one argument with a list expand symbol.

List Expander	Description	Example Code
Cross	The cross product between the lists elements. Command: `cross`	cross \| ex:T(++(1,2,3), ++(10,11)). is equivilant to ex:T(1,10). ex:T(2,10). ex:T(3,10). ex:T(1,11). ex:T(2,11). ex:T(3,11).
Zip Min	Put all elements in the same position in the lists in a template instance, stop when the smallest list reached its end. Command: `zipMin`	zipMin \| ex:T(++(1,2,3), ++(10,11)). is equivalant to ex:T(1,10). ex:T(2,11).
Zip Max	Put all elements in the same position in the lists in a template instance, for smaller lists put none instead of list elements, when size is reached. Command: `zipMax`	zipMax \| ex:T(++(1,2,3), ++(10,11)). is equivalant to ex:T(1,10). ex:T(2,11). ex:T(3,none).

Blank Node

Using an IRI that is in every instance new generated and is not an argument can be a blank node. There are anonymous blank nodes and named blank nodes. Blank nodes with a name can be used in more than one position because it's the same reference name.

Syntax

Anonymous blank nodes are two square brackets [].

A named blank node is an underscore followed by a colon and then the name, e.g. _:myBlankNodeName.

Appearance

The blank nodes are represented by a name derived from the occurrence call execution path, so they appear inside the subobjects as a long name of page names and numbers. This is due to the idea, that every blank node should be the same in different refreshes and little changes.

Side Effects

The implementation differs from the OTTR description such that ?var and _:var do not refer to the same object. As described blank nodes are in this extension pages in the ottr:blank namespace, such that the names of the pages are derived by the execution path (template calls) of an instantiation. Not accepting Blank nodes as an argument can be done with the parameter mode "non-blank" (!)

None Arg

Passing no value to a template means passing the none value. In the current OTTR-version the empty string is not a valid input (even if it is described differently on the website), so pass nothing needs to pass none or ottr:none.

Syntax

The empty string is not valid. Write none or ottr:none.

Side Effects

Internal the extension replaces it by the empty string. A template can behave different to a none input. The template can produce no template calls/instances if there is no optional parameter mode for the argument or can produce template calls, if it is present. If the argument/parameter has a default fall back constant, it uses this instead (completely ignoring the optional parameter mode).

The none argument is used in the list expander zipMax for smaller lists.

OTTR-Literals

The OTTR-Languages accepts (in contrast to RDFs) different types of literals (and not only strings). These literals are integers (e.g. 42), floats (e.g. 3.1415 or 0.7e-10), booleans (true,false) and normal strings with language tag or type hints (e.g. "mystring", "good morning"@en, "11-11-2011"@xsd:date). The mapping to the used IRIs for the types is described here.

The extension writes OTTR literals as strings with the type hint in the triple subobjects.

Automated Forms

The extension Page Forms provides user friendly forms that request the input of a template via normal input fields. An adequate form to a template needs information about the arguments of the template, like kind of best fitting input field and name. Also, adding relevant information for a qualified completion of a form, is important, because the named input field often do not display the requested input.

Because of the adaption of the template call via the OTTR parser, a form for OTTR-templates need to add additional arguments or call a template that inserts the arguments in an OTTR statement. The second variant is the chosen one in the extension implementation.

The OTTR Extension provides an automated form generation for a written template. It assumes the form for the template should have the same name as the template only in the Form-namespace. On the template page the parser generates a button 'Create Form' for generating such page. It automatically includes the needed code, and the user only has to click 'Create Page'. If the form page exists, the button disappears and a link to create a page with an instance of the form appears. The appearance of the whole Form Info Part on the template page can be turn off with an adaption of a Template. For a visual example and information see above.

Signatures

The OTTR-syntax accept a signature followed by a dot as a valid statement. Because there is no purpose in the mediawiki domain for this feature, the extension uses it to generate the form code for a template that has the same signature.

The derived information from the signature is used to generate the input field code for the different arguments and some information around it. It displays the existence of parameter modes and default values. Also, the requested type is shown. The parameters/arguments are ordered by their position and the name (without the ?) is displayed in front of the corresponding input field.

The different parameter/argument modes are described by:

"?": optional argument,
"!": not a blank node ([] or _:example),
"DFLT": default value available

And are places in front of the input field.

The requested type is written after the input field if it is present in the signature. If a list is requested, the syntax of lists is described.

Input Types

Different requested types produce different input types for the input field supported by the page forms extension.

If no type restriction is added to the parameter, the default input form text is used.

Requested Type	Input Type	Description
ottr:IRI	`input type=comboboxvalues from namespace=Main`	Suggesting any page of the namespaces, that are written in the Settings.py
xsd:integer or xsd:float	`input type=text`	no check for number input is known for the field from the page forms extension
xsd:boolean	`input type=dropdown` `values=true,false`	The values for the OTTR parser that parsed as booleans
xsd:string	`input type=textarea`	longer text is possible, but the quote marks are fundamental for the OTTR input anyway.
Other type	`input type=combobox` `values from category=<type_value>`	Search for pages with the requested type as a category.

Multi Instances

On one page you can add multiple instances with one form call. Simply by clicking on the "Add another instance"-button and filling the input fields.

Internally it satisfies the restriction of only one OTTR parser call per page.

Multi Templates

You can also add multiple instances from different templates with one form to a page. This is done by writing multiple signatures in the same OTTR call in the form page (all ending with a dot). In the same order the form will give the user the ability to add instances of any template that correlates to one of the present signatures. The number of different templates depend on how many template pages exists with the name Template:ottr:SingleInstanceForMultiCreationX, where X starts with 1.

If two or more signatures are present in the OTTR form call, none of them will have an empty instance by default when creating a new page.

Drawbacks of Using Forms

Currently it does not display the additional information from the parser to the instances, mainly because of the usage of <noinclude> tags.

Default Forms

The template name of the first signature in the form is used to add a default form to the form with the same name and an edit with form link appears on pages that are created with the form.

Example

The signature of the namedPizza example from above looks like the following:

Implementation Details

The mediawiki representations of the OTTR features are described TODO Help:Extension:OttrParser/ImplementationDetails.

You can change the Error and Warning box appearance by changing the template 'Template:ottr:ErrorMsg', maybe by simple calling a note template or other boxes.

Errors

If an internal unexpected Python Exception occurs the stack trace is printed out on the page.

There are several input errors, that are communicated to the user with a red Error box (the error code numbers are currently somewhat messy).

Error:

...

Code	Trigger	Description
6	Wrong Usage of List expand and List expander	Every `cross`, `ZipMin` and `ZipMax` with a pipe `\|` needs at list one argument in the instantiation code with a list expander sign `++`. And `++` cannot exist without one of them.
5	Wrong Usage of variables/arguments	Variables as arguments are only allowed inside a template and not outside in a normal instance.
4	Input Type does not match with simple type check	The check to the list nesting of the input, ottr:IRI or the literal type string added by the OTTR parser does not match and so the input is not valid
3	Non Blank Check Failed	Detected a ottr:blank in the type string, but the parameter is marked as a non blank argument and so connecting it to a blank node is not valid.
-3	Used Argument name is not defined in the signature	The parameter name used in the template hull does not match with any argument name in the signature. Maybe a typo.
0	Parser Error	The input does not fit to the general syntax rules, described by the language. All other errors above are handled outside the defined syntax because they are not part of it.

Warnings

There are several warnings, that are communicated to the user with a red Warning box.

Warning:

...

Code	Trigger	Description
1	Instances outside a template definition	In a template call (for template definition) there should only be the template definition and no other instances outside the template definition per page and call.
2	More than one template definition	In a template call for template definitions there should only be only one template definition per page and call. (A template correlates with a page inside a template namespace).
-1	Template Name and Page name does not match	For valid automated form generation, the template name specified in the template definition should match the page name of the used page. Also, the instantiation uses the wiki feature by instantiate the template via the page name.
-2	Template definition does not lie in the Template namespace	For using the template correctly, the page should lie in the template namespace (the FULLPAGENAME should start with 'Template:')
7	Non Empty List Check Failure	Type Check for NEList was not successful. Maybe also done because the type of an empty list is not matchable with the type string of NEList<...>
8	Least Upper Bound Check Failure	The check for the LUB<...> was not successful.
9	Type Check with Inferencing Failure	A type check with the category feature inferencing was not successful, maybe because the input does not fit the requirements or the user does not added the types to the reference.

Type Inferencing

Type checks added via type hint to strings and the types of parsed literals are done without the category feature (inside the extension code). Also the ottr:IRI check is also done and the List and NEList check.

The inferencing of types is currently not a feature of the semantic media wiki. The category inferencing comes close to the subClassOf feature and type relation. But to establish this connection to the different IRIs is not done via a simple wikicode on arbitrary pages. It needs the [[Category:XYZ]] on the page equal to the IRI or the Category equal to the Class name. If these pages are not the current page the extension writes the code on, it displays the user a request to add text to these pages. If the pages are not created, it displays a button that fills the edit page of a new page with the needed content. The wikicode for such behavior is written in the following templates:

So, it is recommended to use these templates, if the type restriction in other templates is necessarily.

The LUB type check checks if the written Category on the page is equal to the requested type (so it tries to not use the inferencing).

Task for the user

Before all checks the templates has code for checking, if the needed Code is already on such pages or not (by ask queries of the smw extension)

Type

The type relation is established by put the Category declaration on the normal page of the IRI inside the wiki. If the instance page name is equal to the IRI, the ax:Type template writes the Category silently. If not, it displays an instruction or a button for an easy creation of the page with the Category declaration per preload inside the edit field.

Page does exist (tt:TypeTest1), but is not the current page:

For correct type checking add on page tt:TypeTest1: [[Category:tt:testClass1]]

Page does not exists:

SubClassOf

To establish the SubClassOf relation it is necessarily to get the SubCategory relationship, by adding the Category of the SubClass to the Category Page of the "ParentClass":

If the Category page of the ParentClass (tt:testSubClass) already exists such text occurs:

Please add [[Category:tt:testClass]] to page Category:tt:testSubClass for correct type checking.

If the Category page does not exist:

Set Layout Template via Annotations

If a called annotation template lies in the Layout namespace, the extension adds some other arguments to the called annotation instance, that depend on the arguments of the defined template:

ottr_is_anno with the value 1
ottr_number_anno_args with the value equivalent to the number of arguments of the template.

And for every argument (X from 1 to ottr_number_anno_args):

ottr_anno_arg_name_X the name of the Xth parameter (defined in the template) with the question mark in front of it.
ottr_anno_arg_value_X the passed value of the Xth argument.
ottr_anno_arg_used_default_X 1 or 0 if the default value is used in the instance of the template.

For example, add an annotation with @@Layout:OttrDefaultLayout(ex:mytemplate) with the template name as the first argument (here ex:mytemplate on the page Template:ex:mytemplate).

Ideas for Future Versions

A better type inferencing and type relation saving. Maybe also via subobjects but the hiearchy with the subClassOf relationship is not clear.

Knwon Problems

The SMW Extension does not accept special characters in the subobject like [ ]. Do not use them in string literals.
The nesting depth of templates can be limited in use, due to the execution/parsing depth of the wiki.