Extension:OttrParser

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

The extension is not secure. Only trusted users should be allowed to edit pages when the extension is activated. So currently it is only for private wikis.

More information about the usage, see Help:Extension:OttrParser

Installation

 * Download and place the file(s) in a directory called  in your   folder or clone the repo directly.
 * run  This will add a new python environment that will be used by the extension.
 * Alternatively you can install the  package from source in any python environment you like and change the   such that it is called from your path.
 * Add the following code at the bottom of your LocalSettings.php:
 * wfLoadExtension( 'OttrParserExtension' );

'''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.'''


 * 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 page Import.


 * ✅ - Navigate to Special:Version on your wiki to verify that the extension is successfully installed.

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

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 employees, that calls another template for persons and add some relationships to the id of the person, that contain information about the occupation, could be part of the page ex:Employee in the template namespace: &lt;ottr&gt; ex:Employee[?id, ?name, ?occupation, ?salary, ?birthdate, ?address] :: { ex:person(?id, ?name, ?birthdate, ?address), ottr:Triple(?id, ex:has_salary, ?salary), ottr:Triple(?id, ex:has_qualification, ?occupation), ottr:Triple(?id, ex:employed_by, ex:this_company) }. &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.

Instantiate templates on normal pages, so that it produces triple instances on that page: &lt;ottr&gt; ex:Employee(ex:emp_003, "John Doe", job:personnel_manager, 3000, "1-1-1965"^xsd:date, "Any Street - Any City - Any State 12345"). ex:Employee(ex:emp_001, "Jane Doe", job:ceo, 4000, "31-12-1964"^xsd:date, "Any Street - Any City - Any State 12345"). &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