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
[edit]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
[edit]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
[edit]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
[edit]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
[edit]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
[edit]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
[edit]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:
Template:ottr:DebugOnOFF
[edit]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
[edit]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
[edit]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
[edit]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
[edit]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
[edit]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
[edit]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:
- The statement is already on the prefix page:
The prefix statement has no effect and no appearance.
Side Effects
[edit]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
[edit]Text declared as a comment is ignored by the parser.
The OTTR-syntax provides single- (# ...) and multi-line (/*** ... ***/) comments.
Template Definition
[edit]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
[edit]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
[edit]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
[edit]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
[edit]| 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:
Request a List or nested lists the OTTR-syntax provides the 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).
|
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
[edit]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
[edit]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
[edit]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
[edit]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
[edit]OTTR comes with the functionality to handle a set of arguments in lists.
Define a List
[edit]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
[edit]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
[edit]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
[edit]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
[edit]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
[edit]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
[edit]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
[edit]The empty string is not valid. Write none or ottr:none.
Side Effects
[edit]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
[edit]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
[edit]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
[edit]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
[edit]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
[edit]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
[edit]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
[edit]Currently it does not display the additional information from the parser to the instances, mainly because of the usage of <noinclude> tags.
Default Forms
[edit]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
[edit]The signature of the namedPizza example from above looks like the following:
Implementation Details
[edit]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
[edit]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).
| 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
[edit]There are several warnings, that are communicated to the user with a red Warning box.
| 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
[edit]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
[edit]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
[edit]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
[edit]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
[edit]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_annowith the value 1ottr_number_anno_argswith 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_Xthe name of the Xth parameter (defined in the template) with the question mark in front of it.ottr_anno_arg_value_Xthe passed value of the Xth argument.ottr_anno_arg_used_default_X1 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
[edit]A better type inferencing and type relation saving. Maybe also via subobjects but the hiearchy with the subClassOf relationship is not clear.
Knwon Problems
[edit]- 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.