Extension:OttrParser



The OttrParser extension parses OTTR Statements and produces wikitext that has equivalent behaviour, storing triples with the Semantic MediaWiki extension. It also provides automated form generation for the Page Forms extension.

For more information about general usage, see Help:Extension:OttrParser

The extension comes with an API to export and import ottr templates from .strottr files. Find more information on features and usage here: Help:Extension:OttrParser/API

'''WARNING! Because of the passing of the input to a python call, this extension is in the current form not considered as secure. Only trusted users should be allowed to edit pages when the extension is activated.'''

Docker Installation
We supply a docker image with a full installation of semantic MediaWiki and the OttrParserExtension, ready to go. To set it up, do the following:


 * 1) Pull and install the image with  You can change the name OTTRWIKI as well as the port 8080 to your liking.
 * 2) Go to http:localhost:8080 and setup you wiki.
 * 3) Save the LocalSettings.php somewhere you remember.
 * 4) Download the after_setup_script with  and make it executable with
 * 5) finish the installation with
 * 6) ✅ You can now enter your wiki at http:localhost:8080
 * 7) (Optional) Check out the API docs at http://localhost:5000
 * 8) (Optional) Add to the wiki

Docker Update
To update the extension, run

Manual Installation

 * 1) clone the repo directly from your extensions folder with
 * 2) or download and place the file(s) in a directory called   in your   folder
 * 3) run   from the repository root. This will add a new python environment that will be used by the extension.
 * 4) or you can install the   package from source in any python environment you like with   and change the   such that it is called from your path. If the package is installed correctly you can find the path e.g. with the command
 * 5) Add the following code at the bottom of your LocalSettings.php: wfLoadExtension( 'OttrParserExtension' );
 * 6) install and add  to you
 * 7) The extension transfers some of the code into templates, for this you must import these pages, from the   file in the repository of the extension, for Example via the Browser Interface on the Special:Import page.
 * 8) ✅ - Navigate to Special:Version on your wiki to verify that the extension is successfully installed.
 * 9) (Optional) Start the OttrAPI with  and check out the documentation at http://localhost:5000
 * 10) (Optional) Add to the wiki Help:Extension:OttrParser
 * 1) (Optional) Add to the wiki Help:Extension:OttrParser

Manual Update
If you installed the extension via git, use where $MEDIAWIKI_ROOT is replaced by the path to the root folder of your mediawiki installation.

You can also manually update the extension by downloading the files and overwriting the old ones. Then you still need to run from the extension folder.

Dependencies
MediaWiki Extensions:
 * Semantic MediaWiki (Homepage)
 * ParserFunctions
 * Loops
 * Arrays
 * Page Forms
 * InputBox
 * AutoCreatePage

Custom Namespaces
By default, you can only define ottr templates in the template namespace. If you want to define ottr template in a custom namespace you need to


 * 1) Define a new namespace in your LocalSettings.phpː
 * 2) Add the namespace to your Settings.py. Add the value of $wgExtraNamespaces to the ottr_template_namespaces variable.

In a Nutshell
With OTTR you can define and instantiate templates with a defined syntax with additional features for parameters/arguments and also Lists of terms and different literal types handled by the parser. Using OTTR templates brings benefits, geared towards the field of RDF generation, among others: Main part is the template definition and the instantiation. The media wiki environment offers the separation part of template definition and instantiation through its inner logic on different pages: Definitions on pages in the Template namespace and the instantiation in other namespaces. A very simple example is shown in this section. The next section shows a more complex example that shows more of the features of the OTTR-language inside the pizza ontology.
 * better abstraction
 * uniform modeling
 * moduloar, encapsulated patterns
 * seperation of design and content

Write a template (on a page in the Template Namespace and use the page name as the template name). For example a template for Pizzas, that is a subclass of the more general 'Pizza' class and has a name: &lt;ottr&gt; dpm:ExampleNamedPizza[ottr:IRI ?name, xsd:string ?label] :: { ax:SubClassOf(?name,ex:Pizza), ottr:Triple(?name, rdfs:label, ?label) }. &lt;/ottr&gt; Parameters can have different options (see the example in the next section), the variable names can be used inside the template hull. They have to start with a question mark. There you can call other templates for a complex hierarchy of template instantiation. The Base of template hierarchies are "Base-Templates" that produce the final data on the page. Here it is ottr:Triple and ax:SubClassOf.

Instantiate templates on normal pages, so that it produces triple instances on that page: &lt;ottr&gt; dpm:ExampleNamedPizza(dpm:ExamplePizza1, "Example"^^xsd:string). &lt;/ottr&gt; Besides the normal literal syntax of the turtle and rdf grammar, the OTTR-syntax provides an easier literal definition for numbers (integers and floats) and booleans. Inside the subobjects they are written like normal string literals with a type hint.

The OTTR-language only provides argument passing via position and not via name.

The extension generates for every triple a subobject from the SMW Extension that contains the subject, predicate and object.

Automated Forms
Generate forms (Page Forms extension) for the written OTTR templates, so that the information in the signature of the template (optional, default value, type etc.) is used to extend the input fields with the correct annoations. The extension generates a button for creating a new form page and prefills the needed code for the page inside the editor. For a more detailed description see #Automated_Forms and an example of the appearance of the button see here.

Overview Example
Templates instantiate other templates. Base templates are the fundament templates, that produces the triples (Here the ottr:Triple template). Example from the Pizza ontology :

&lt;ottr&gt; ex:NamedPizza[owl:Class ?pizza, ? owl:NamedIndividual ?country, NEList ?toppings = (ex:TomatoSauce)] :: { ax:SubClassOf(?pizza, ex:NamedPizza), ax:SubObjectHasValue(?pizza, ex:hasCountryOfOrigin, ?country), ax:SubObjectAllValuesFrom(?pizza, ex:hasTopping, _:toppingsUnion), rstr:ObjectUnionOf(_:toppingsUnion, ?toppings), cross | ax:SubObjectSomeValuesFrom(?pizza, ex:hasTopping, ++?toppings) } . &lt;/ottr&gt; This example template from the OTTR-website uses different features (all implemented OTTR features are described in detail in the other sections):
 * ?, marking a parameter/argument as optional and so the input can be set to  or , so that the instances of the templates are executed otherwise the template does not produce any output if arguments (without the parameter option) have the value equal to  . (Another parameter option in the Non-Blank option !, that is also written in front of the argument name and an optional type restriction).
 * _:toppingsUnion, blank nodes generate new IRIs (references) for every instance of the template without putting an explicit IRI inside the template (Non-Blank parameter option ! throws an error if the value of an argument is a blank node).
 * cross | ... ++, list expand and list expander that handles different list behavior to instantiation of templates and triples with lists as arguments, so that every entry in a list gets an own instance. There is the cross (-product), ZipMin and ZipMax for multiple lists as arguments for an instance, that connects the entries of the different lists in nonidentical ways.
 * owl:Class, NEList, type check of the arguments. In this case to IRIs with the type of owl:class and inputs of not empty lists with entries of any IRI look. In the extension this feature is best working for literal types and Lists, but the type interference of the input needs some additional attention by the user.
 * = (ex:TomatoSauce) default value such that if a  value is passed the default value is used. (Added inside this example for this documentation)

Instantiate Templates, that produce triples on the page. &lt;ottr&gt; ex:NamedPizza(ex:Margherita, ex:Italy, (ex:Mozzarella, ex:Tomato)). ex:NamedPizza(ex:Hawaii, none, (ex:Cheese, ex:Ham, ex:Pineapple)). &lt;/ottr&gt; Inside a media wiki, that handles such themes it would be, for example, plausible to write the first instance on the ex:Margherita and second on the ex:Hawaii, so that the information is stored on the correlated pages.

Subtemplates
A base template can be defined like here : &lt;ottr&gt;ottr:Triple [ ottr:IRI ?subject, ! ottr:IRI ?predicate, rdfs:Resource ?object ] :: BASE .&lt;/ottr&gt;

Other templates that create rdf(s) relationships like subclasses, etc. (Often with a more complex triple call than just one call): &lt;ottr&gt; ax:SubClassOf[ ottr:IRI ?subclass, ottr:IRI ?parentclass ] :: {   ottr:Triple(?subclass, rdfs:subClassOf, ?parentclass) } . &lt;/ottr&gt;

Implementation Details
The generated code is not saved on the page, like all normal parser tags. An exception is the usage of the, which replaces the call directly while the page saving process.

For more see Help:Extension:OttrParser