-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathOTTR-Relevant-Pages.xml
1726 lines (1524 loc) · 108 KB
/
OTTR-Relevant-Pages.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<mediawiki xmlns="http://www.mediawiki.org/xml/export-0.10/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.mediawiki.org/xml/export-0.10/ http://www.mediawiki.org/xml/export-0.10.xsd" version="0.10" xml:lang="en">
<siteinfo>
<sitename>DiProMag</sitename>
<dbname>smw</dbname>
<base>https://dipromag.techfak.uni-bielefeld.de/w/index.php/Main_Page</base>
<generator>MediaWiki 1.34.2</generator>
<case>first-letter</case>
<namespaces>
<namespace key="-2" case="first-letter">Media</namespace>
<namespace key="-1" case="first-letter">Special</namespace>
<namespace key="0" case="first-letter" />
<namespace key="1" case="first-letter">Talk</namespace>
<namespace key="2" case="first-letter">User</namespace>
<namespace key="3" case="first-letter">User talk</namespace>
<namespace key="4" case="first-letter">DiProMag</namespace>
<namespace key="5" case="first-letter">DiProMag talk</namespace>
<namespace key="6" case="first-letter">File</namespace>
<namespace key="7" case="first-letter">File talk</namespace>
<namespace key="8" case="first-letter">MediaWiki</namespace>
<namespace key="9" case="first-letter">MediaWiki talk</namespace>
<namespace key="10" case="first-letter">Template</namespace>
<namespace key="11" case="first-letter">Template talk</namespace>
<namespace key="12" case="first-letter">Help</namespace>
<namespace key="13" case="first-letter">Help talk</namespace>
<namespace key="14" case="first-letter">Category</namespace>
<namespace key="15" case="first-letter">Category talk</namespace>
<namespace key="102" case="first-letter">Property</namespace>
<namespace key="103" case="first-letter">Property talk</namespace>
<namespace key="106" case="first-letter">Form</namespace>
<namespace key="107" case="first-letter">Form talk</namespace>
<namespace key="108" case="first-letter">Concept</namespace>
<namespace key="109" case="first-letter">Concept talk</namespace>
<namespace key="112" case="first-letter">smw/schema</namespace>
<namespace key="113" case="first-letter">smw/schema talk</namespace>
<namespace key="114" case="first-letter">Rule</namespace>
<namespace key="115" case="first-letter">Rule talk</namespace>
<namespace key="3000" case="first-letter">Dpm</namespace>
</namespaces>
</siteinfo>
<page>
<title>Ottr:Documentation</title>
<ns>0</ns>
<id>453</id>
<revision>
<id>3202</id>
<parentid>3201</parentid>
<timestamp>2021-10-16T09:34:17Z</timestamp>
<contributor>
<username>Florian Schröder</username>
<id>23</id>
</contributor>
<model>wikitext</model>
<format>text/x-wiki</format>
<text xml:space="preserve" bytes="46578">This extension provides a parsing of [https://ottr.xyz/ 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.
== 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. Main part is the template definition and the instantiation. 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.
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:
<pre>
&lt;ottr&gt;
ex:Employee[?id, ?name, ?occupation, ?salary, ?birthdate, ?address] :: {
ex:person(?id, ?name, ?birthdate, ?adress),
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;
</pre>
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:
<pre>
&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;
</pre>
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 does only provide 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.
<pre>
{{#subobject: |subject={{{1}}} |predicate={{{2}}} |object={{{3}}} |subobject-category=OTTR-Triple }}
</pre>
== 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 [https://ottr.xyz/#Template_definition] :
<pre>
&lt;ottr&gt;
ex:NamedPizza[owl:Class ?pizza, ? owl:NamedIndividual ?country, NEList<ottr:IRI> ?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;
</pre>
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 <code>none</code> or <code>ottr:none</code>, 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 <code>none</code>. (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 different.
* '''owl:Class''', '''NEList<ottr:IRI>''', 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 <code>none</code> value is passed the default value is used. (Added inside this example for this documentation)
Instantiate Templates, that produce triples on the page.
<pre>
&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;
</pre>
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.
==== Sub Templates ====
A base template can be defined like here [https://primer.ottr.xyz/01-basics.html#5.3_NonBlank_parameters]:
<pre>&lt;ottr&gt;ottr:Triple [ ottr:IRI ?subject, ! ottr:IRI ?predicate, rdfs:Resource ?object ] :: BASE .&lt;/ottr&gt;</pre>
Other templates that create rdf(s) relationships like subclasses, etc. Often with a more complex triple call than just one call:
<pre>
&lt;ottr&gt;
ax:SubClassOf[
ottr:IRI ?subclass,
ottr:IRI ?parentclass
] :: {
ottr:Triple(?subclass, rdfs:subClassOf, ?parentclass)
} .
&lt;/ottr&gt;
</pre>
== Installation ==
The parser and converter are completely written in python, so the extension needs a working python3 access. In the current 'Hooks' PHP-file it calls a python interpreter of an '''Anaconda''' installation in the <code>extensions</code> directory and an environment named ''ottr_ext''. Change the call to your needs. Because of the passing of the input to a python call, this extension is in the current form <span style="color:orange">not considered as secure</span>. Only trusted users should be allowed to edit pages when the extension is activated.
The scripts needs the following python library dependencies:
* [https://pypi.org/project/antlr4-python3-runtime/ ANTLR4] (<code>pip3 install antlr4-python3-runtime</code>)
Load the extension like other extensions with <code>wfLoadExtension( 'OttrParserExtension' );</code> in the LocalSettings.php.
The extension transfers some of the code in templates, for this '''you have to import these pages''', from the file in the repository of the extension.
=== Dependencies ===
MediaWiki Extensions:
* [https://www.mediawiki.org/wiki/Extension:Semantic_MediaWiki Semantic Media Wiki] ([https://www.semantic-mediawiki.org/wiki/Semantic_MediaWiki Homepage])
* [https://www.mediawiki.org/wiki/Extension:ParserFunctions ParserFunctions]
* [https://www.mediawiki.org/wiki/Extension:Loops Loops]
* [https://www.mediawiki.org/wiki/Extension:Arrays Arrays]
* [https://www.mediawiki.org/wiki/Extension:Page_Forms Page Forms]
* [https://www.mediawiki.org/wiki/Extension:InputBox InputBox]
== General Usage of the Extension ==
Parse and replace OTTR text with wikicode are done via one of the following OTTR calls.
Important is that '''<span style="color:red">on every page there should only be ONE OTTR call</span>''' 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.
&lt;ottr&gt; ... &lt;/ottr&gt;
The advantage of the html tag is the disuse of the pipe character <code>|</code> and equal sign <code>=</code> 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.
&lt;ottr form=True&gt; ... &lt;/ottr&gt;
=== OTTR Function ===
For [https://www.mediawiki.org/wiki/Help:Substitution#Multilevel_substitution safe substitution], the extension provides a parser function for templates.
'''Example'''<br/>
Include something like this in your Template page:
<nowiki>{{safesubst:#ottrFunction: ... }}</nowiki>
The extension writes the safesubst call again in the page, but surrounded with HTML-Comment characters (<code>&lt;!----&gt;</code>). For recalling 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:''
<blockquote>
'''OTTR-Definition:'''
<pre>
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)
} .
</pre>
</blockquote>
===== 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:''
<blockquote>
'''Form Info:'''<br/>
The OTTR-Extension comes with an automated form creation, which simplifies the generation of instances of a template via input fields:
<inputbox>
type=create
hidden=yes
default=Main Page
buttonlabel=Create Form
</inputbox>
</blockquote>
''Example Appearance of a link to create an instance of the template:''
<blockquote>
'''Form Info:'''<br/>
The OTTR-Extension comes with an automated form creation, which simplifies the generation of instances of a template via input fields:
: [[Main Page|Create instance with form]]
</blockquote>
===== 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:''
<blockquote>
'''Debug Info:'''
* ''Number Init Triples:'' '''3'''
* ''Number Used IRIs:'' '''6'''
* ''Max Depth:'' '''2'''
* ''Used Templates:''
:- ex:Template1: '''1'''<br/>- ottr:Triple: '''3'''
</blockquote>
===== 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 [[#Set Layout Template via Annotations|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:''
<blockquote>
'''Generated Triples:''' ''(Needs sometimes 2x refreshes)''
<table class="sortable wikitable smwtable jquery-tablesorter"><tr><th class="headerSort" tabindex="0" role="columnheader button" title="Sort ascending">&nbsp;</th><th class="Subject headerSort" tabindex="0" role="columnheader button" title="Sort ascending"><span style="color:#4371cf;">Subject</span></th><th class="Predicate headerSort" tabindex="0" role="columnheader button" title="Sort ascending"><span style="color:#4371cf;">Predicate</span></th><th class="Object headerSort" tabindex="0" role="columnheader button" title="Sort ascending"><span style="color:#4371cf;">Object</span></th></tr><tr data-row-number="1" class="row-odd"><td class="smwtype_wpg"><span class="smw-subobject-entity" style="color:#2a4b8d">ExampleInstances:Template1</span></td><td class="Subject smwtype_wpg"><span style="color:#dd3333;">Ex:TestPara1</span></td><td class="Predicate smwtype_wpg"><span style="color:#dd3333;">Ex:testPredicate</span></td><td class="Object smwtype_wpg"><span style="color:#dd3333;">Ex:testObject</span></td></tr><tr data-row-number="2" class="row-even"><td class="smwtype_wpg"><span class="smw-subobject-entity"><span style="color:#2a4b8d;">ExampleInstances:Template1</span></td><td class="Subject smwtype_wpg"><span style="color:#dd3333;">Ex:testSubject</span></td><td class="Predicate smwtype_wpg"><span style="color:#dd3333;">Ex:testPredicate</span></td><td class="Object smwtype_wpg"><span style="color:#dd3333;">Ex:TestPara3</span></td></tr><tr data-row-number="3" class="row-odd"><td class="smwtype_wpg"><span class="smw-subobject-entity" style="color:#2a4b8d">ExampleInstances:Template1</span></td><td class="Subject smwtype_wpg"><span style="color:#dd3333;">Ex:testSubject</span></td><td class="Predicate smwtype_wpg"><span style="color:#dd3333;">Ex:TestPara2</span></td><td class="Object smwtype_wpg"><span style="color:#dd3333;">Ex:testObject</span></td></tr></table>
</blockquote>
===== Template:ottr:DisplayCode =====
Display the generated Wikicode for the instances or template on a page.
''Example Appearance:''
<blockquote>
'''Wikicode:'''
<pre>
{{#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}}}}
</pre>
</blockquote>
== Prefixes and Comments ==
The extension uses prefixes from RDFs as namespaces of the wiki, e.g. the page of the IRI <code>xsd:integer</code> 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, <span style="color:orange">the extension wants to collect all Prefix information on one page</span>. 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 <code>@prefix</code> and states then the prefix and the URL (in <code><</code> and <code>></code> signs) separated by a colon. It ends (like every OTTR statement) with a dot, e.g.
<pre>
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
</pre>
===== Appearance =====
The displaying result depends on different preconditions:
* The statement is on the prefix page:
<blockquote>
# Prefix: '''xsd''': <http://www.w3.org/2001/XMLSchema#>
</blockquote>
* The statement is on another page and the prefix is not defined on the prefix page:
<blockquote>
<table class="warning-message" cellspacing="0" cellpadding="0" border="0" style="box-sizing:border-box; border:1px #d33 solid; background: transparent; margin:0.5em 0;padding:0.5em;background-color: #fee7e6"><tr><td nowrap="nowrap" valign="top">'''Warning:''' </td><td valign="top">&emsp;Prefix '''pt2''' is not defined on page [[Main Page|Ottr:OttrPrefixes]]!</td></tr></table>
</blockquote>
* The statement is already on the prefix page:
<blockquote>
The prefix statement has no effect and no appearance.
</blockquote>
===== Side Effects =====
On the Prefix page it produces also a ''subobject'' with the properties:
; IRI
: The complete URL without the <code><</code> and <code>></code>.
; Namespace
: The prefix name.
; Subobject-category
: <code>OTTR-Prefix</code>, for querying.
The Warning message produces like every error and warning box also a ''subobject'' of the subobject-category <code>OTTR-Error</code>, containing the message and a simple error code.
=== Comments ===
Text declared as a comment is ignored by the parser.
The OTTR-syntax provides single- (<code># ...</code>) and multi-line (<code>/*** ... ***/</code>) 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.
<span style="color:orange">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.</span>
===== 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 <code>[ ]</code>and are separated by commas <code>,</code>. The name of the argument starts with a <code>?</code>. For additional parameter/argument features see the table below.
The signature and the template hull is connected with double colons <code>::</code>. The list of template calls inside the hull are surrounded with curly brackets <code>{ }</code> and separated by commas <code>,</code>. Only the Base template is declared via the template hull: <code>BASE</code>. 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 <code>.</code>.
An example of a BASE Template and a template with 2 inner template calls:
<pre>
ottr:Triple[?subject, ?predicate, ?object] :: BASE .
</pre>
<pre>
ex:Template_1[?arg1, ?arg2, ?arg3] :: {
ottr:Triple(?arg1, ex:PredictateTest1, ?arg2),
ottr:Triple(?arg1, ex:PredictateTest2, ?arg3)
} .
</pre>
===== 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 [[#Set Layout Template via Annotations|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 ====
{| class="wikitable"
!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 <code>?</code>. 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.
| <pre>ex:Template[? ?arg1, ?arg2, ? xsd:integer ?arg3]</pre> 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 <code>=</code> that separated the argument name and the default value.
| <pre>ex:Template[? ?arg1, ?arg2 = ex:info, ? xsd:integer ?arg3 = 0]</pre> The second and third parameter/argument have a default value (the IRI ''<code>ex:info</code>'' and the number ''<code>0</code>''). 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 <code>!</code>. 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.
| <pre>ex:Template[?! ?arg1, ! ?arg2, ? xsd:integer ?arg3]</pre> 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 <code>^^</code>) 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|Type Inferencing]] for establishing such relationship inside the wiki.
<span id="OTTR-Type-To-IRI">The IRIs for the different simple types are:</span>
* '''integer''': <code>xsd:integer</code> (''it also gets the additional types <code>xsd:float</code> and <code>rdfs:resource</code>)
* '''float''': <code>xsd:float</code> (''it also gets the additional type <code>rdfs:resource</code>)
* '''boolean''': <code>xsd:boolean</code> (''it also gets the additional type <code>rdfs:resource</code>)
* '''IRI''': <code>ottr:IRI</code> (''it also gets the additional type <code>rdfs:resource</code>)
Request a '''List''' or nested lists the OTTR-syntax provides the <code>List</code> word with the requested type of the elements of the list inside <code>< ></code>. Also request '''Not-Empty Lists''' with <code>NEList</code>
And also, the '''LUB''' restriction, such that the input has to be a direct instance of a type without nested subclass behavior.
| <pre>ex:Template[?! List<xsd:float> ?arg1, ! ?arg2, ? xsd:integer ?arg3]</pre> The first argument restricts its input to lists of numbers and the third to integers.
<pre>ex:Template[?! NEList<xsd:date> ?arg1, ! ?arg2, ottr:IRI ?arg3]</pre> Here the first argument tries to get a not empty list of dates. Such inputs could be <code>"MyDataInMyDateFormatHere"^^xsd:date</code>. 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 <code>,</code>. Each template annotation call starts with <code>@@</code>, 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 [[#Set Layout Template via Annotations|here]] for more information.
| <pre>ex:Template[?! ?arg1, ! ?arg2, ? xsd:integer ?arg3]
@@ex:AnnoTemplate(ex:Template, 2, 3),
@@ex:AnnoTemplate2(ex:Template, "argument string")
</pre> The <code>ex:Template</code> has two annoations template calls.
<pre>ex:Template2[?! ?arg1, ! ?arg2, ? xsd:integer ?arg3]
@@Layout:MyLayoutTemplate(ex:Template, 2, 3)
</pre> The <code>ex:Template2</code> 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 <code>( )</code>, separated by commas <code>,</code>, 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.
<pre>
ex:Template(ex:test, 4, "testString"@en) .
</pre>
===== 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 [[#Type Inferencing|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 <code>OTTR-Triple</code>. If errors or warnings occur also the categories <code>OTTR-Error</code>.
<pre>
{{#subobject: |subject={{{1}}} |predicate={{{2}}} |object={{{3}}} |subobject-category=OTTR-Triple }}
</pre>
=== 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 <code>( )</code> and separated by commas <code>,</code>. A list can contain any normal input of the underlying position.
<pre>(1,2,3,4)</pre>
<pre>(ex:elem1, ex:elem2, ex:elem3)</pre>
<pre>(4, ex:elem3, 5.6, false, "test")</pre>
<pre>((1,1),(1,2),(1,3))</pre>
===== 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) <code>++</code> is needed for an expand. Furthermore, a list expander command is needed in front of the instance (separated by a vertical bar/pipe <code>|</code>). 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 <code>()</code>.
<pre>zipMin | ex:Template(++(1,2,3,4), ("a number","a symbol"), ++("one", "two", "three", "four")).</pre>
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 <code>ex:Template</code>-template, e.g.
<pre>
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").
</pre>
The different list expander only produces different behavior, if there are more than one argument with a list expand symbol.
{| class="wikitable"
!List Expander
!Description
!Example Code
|-
| Cross
| The cross product between the lists elements. Command: <code>cross</code>
| <pre>cross | ex:T(++(1,2,3), ++(10,11)).</pre> is equivilant to
<pre>ex:T(1,10).
ex:T(2,10).
ex:T(3,10).
ex:T(1,11).
ex:T(2,11).
ex:T(3,11).</pre>
|-
| 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: <code>zipMin</code>
| <pre>zipMin | ex:T(++(1,2,3), ++(10,11)).</pre> is equivalant to
<pre>
ex:T(1,10).
ex:T(2,11).
</pre>
|-
| 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: <code>zipMax</code>
| <pre>zipMax | ex:T(++(1,2,3), ++(10,11)).</pre> is equivalant to
<pre>
ex:T(1,10).
ex:T(2,11).
ex:T(3,none).
</pre>
|}
=== 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 <code>[]</code>.
A named blank node is an underscore followed by a colon and then the name, e.g. <code>_:myBlankNodeName</code>.
===== 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 <code>?var</code> and <code>_:var</code> do not refer to the same object [https://spec.ottr.xyz/stOTTR/0.1/#2.3_Terms].
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" (<code>!</code>)
=== 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 <code>none</code> or <code>ottr:none</code>.
===== Syntax =====
The empty string is not valid. Write <code>none</code> or <code>ottr:none</code>.
===== 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 <code>zipMax</code> 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. <code>42</code>), floats (e.g. <code>3.1415</code> or <code>0.7e-10</code>), booleans (<code>true</code>,<code>false</code>) 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 [[#OTTR-Type-To-IRI|here]].
<span style="color:orange">The extension writes OTTR literals as strings with the type hint in the triple subobjects.</span>
== 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 [[#Template:ottr:DisplayFormHelp|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 <code>?</code>) 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 <code>text</code> is used.
{| class="wikitable"
!Requested Type
!Input Type
!Description
|-
| '''ottr:IRI'''
| <code>input type=combobox</code><code>values from namespace=Main</code>
| Suggesting any page of the namespaces, that are written in the Settings.py
|-
| '''xsd:integer''' or '''xsd:float'''
| <code>input type=text</code>
| no check for number input is known for the field from the page forms extension
|-
| '''xsd:boolean'''
| <code>input type=dropdown</code> <code>values=true,false</code>
| The values for the OTTR parser that parsed as booleans
|-
| '''xsd:string'''
| <code>input type=textarea</code>
| longer text is possible, but the quote marks are fundamental for the OTTR input anyway.
|-
| ''Other type''
| <code>input type=combobox</code> <code>values from category=<type_value></code>
| 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 <code>Template:ottr:SingleInstanceForMultiCreationX</code>, 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 &lt;noinclude&gt; 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:
<blockquote>
[[File:NamedPizzaForm.png|1000px]]
</blockquote>
== Implementation Details ==
The mediawiki representations of the OTTR features are described [[ottr:Feature Representation|here]].
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.
<table class="warning-message" cellspacing="0" cellpadding="0" border="0" style="box-sizing:border-box; border:1px #d33 solid; background: transparent; margin:0.5em 0;padding:0.5em;background-color: #fee7e6"><tr><td nowrap="nowrap" valign="top">'''Error:''' </td><td valign="top">&emsp; ... </td></tr></table>
{| class="wikitable"
!Trigger
!Description
|-
| Wrong Usage of List expand and List expander
| Every <code>cross</code>, <code>ZipMin</code> and <code>ZipMax</code> with a pipe <code>|</code> needs at list one argument in the instantiation code with a list expander sign <code>++</code>. And <code>++</code> cannot exist without one of them.
|-
| Wrong Usage of variables/arguments
| Variables as arguments are only allowed inside a template and not outside in a normal instance.
|-
| 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
|-
| 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.
|-
| 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.
|-
| 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.
<table class="warning-message" cellspacing="0" cellpadding="0" border="0" style="box-sizing:border-box; border:1px #d33 solid; background: transparent; margin:0.5em 0;padding:0.5em;background-color: #fee7e6"><tr><td nowrap="nowrap" valign="top">'''Warning:''' </td><td valign="top">&emsp; ... </td></tr></table>
{| class="wikitable"
!Trigger
!Description
|-
| 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.
|-
| 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).
|-
| 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.
|-
| 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:')
|-
| 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<...>
|-
| Least Upper Bound Check Failure
| The check for the LUB<...> was not successful.
|-
| 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 <code><nowiki>[[Category:XYZ]]</nowiki></code> 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:
* [[Template:ax:SubClassOf]]
* [[Template:ax:Type]]
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) (See [https://spec.ottr.xyz/mOTTR/0.1/#2.1_Types] 5th paragraph).
===== 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:
<blockquote>
''For correct type checking add on page'' '''<span style="color:blue">tt:TypeTest1</span>''': <code><nowiki>[[Category:tt:testClass1]]</nowiki></code>
<blockquote>
* Page does not exists:
</blockquote>
<inputbox>
type=create
hidden=yes
default=Main Page
buttonlabel=Create Page tt:TypeTest1 for correct type checking.
</inputbox>
</blockquote>
====== 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:
<blockquote>
''Please add'' <code><nowiki>[[Category:tt:testClass]]</nowiki></code> ''to page'' <span style="color:blue">Category:tt:testSubClass</span> ''for correct type checking.''
</blockquote>
* If the Category page does not exist:
<blockquote>
<inputbox>
type=create
hidden=yes
default=Main Page
buttonlabel=Create Category for correct type checking.
</inputbox>
</blockquote>
==== 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:
* <code>ottr_is_anno</code> with the value '''1'''
* <code>ottr_number_anno_args</code> with the value equivalent to the number of arguments of the template.
And for every argument ('''X''' from 1 to <code>ottr_number_anno_args</code>):
* <code>ottr_anno_arg_name_'''X'''</code> the name of the Xth parameter (defined in the template) with the question mark in front of it.
* <code>ottr_anno_arg_value_'''X'''</code> the passed value of the Xth argument.
* <code>ottr_anno_arg_used_default_'''X'''</code> 1 or 0 if the default value is used in the instance of the template.
For example, add an annotation with <code>@@Layout:OttrDefaultLayout(ex:mytemplate)</code> with the template name as the first argument (here 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 <code>[ ]</code>. Do not use them in string literals.</text>
<sha1>4dyjrnk01eyowt0rok3t1e83b2y3yom</sha1>
</revision>
</page>
<page>
<title>Ottr:Overview</title>
<ns>0</ns>
<id>486</id>
<revision>
<id>3150</id>
<parentid>3149</parentid>
<timestamp>2021-09-21T09:55:46Z</timestamp>
<contributor>
<username>Florian Schröder</username>
<id>23</id>
</contributor>
<model>wikitext</model>
<format>text/x-wiki</format>
<text xml:space="preserve" bytes="2186">Welcome to the OTTR-Overview page from here you should get all the links to important pages used by the OTTR-Extension.
== Documentation ==
Further information about the usage of the extension, like parser call and ottr-syntax can be found here: [[Ottr:Documentation]].
Implementation details about single ottr features are described [[Ottr:Feature Representation|here]].
== Defined Prefixes ==
All prefixes should be defined on one page: [[Ottr:OttrPrefixes]].
== Pages with one or more Errors ==
You can ask for SMW-Subobjects with the predicate "Subobject-Category" equal to OTTR-Error or look on page: [[Ottr:ErrorPages]]
== All initialised Triples ==
You can ask for SMW-Subobjects with the predicate "Subobject-Category" equal to OTTR-Triple or look on page: [[Ottr:AllTriples]]
== Appearance Templates ==
Change the display behavior of different additional parser information to the user, simply by turning them off and on by changing the 1 to a 0 and vis versa.
* [[Template:ottr:DebugOnOFF]]
* [[Template:ottr:AllAnnotationsOnOff]]
* [[Template:ottr:DisplayTriplesOnOff]]
* [[Template:ottr:DisplayCode]]
* [[Template:ottr:DisplayOttr]]
* [[Template:ottr:DisplayFormHelp]]
== Util Templates ==
The Extension uses some templates for internal processing, if you want some changes or look into the internal mechanics of the templates, here they are:
* [[Template:ottr:ListType]]
* [[Template:ottr:Prefix]]
* [[Template:ottr:PrefixCheck]]
* [[Template:ottr:ErrorMsg]]
* [[Template:ottr:AskForTriples]]
* [[ottr:FormTemplate]] ''(The preloaded file for the automated form)''
* [[ottr:SubCategoryTemplate]] ''(The preloaded file for the autoincluded subcategory)''
* [[Template:ottr:MultiInstanceCreation]]
* [[Template:ottr:SingleInstanceForMultiCreation]]
* [[Template:ottr:SingleInstanceForMultiCreation1]]
* [[Template:ottr:SingleInstanceForMultiCreation2]]
* [[Template:ottr:SingleInstanceForMultiCreation3]]
* [[Template:ottr:SingleInstanceForMultiCreation4]]
* [[Template:ottr:SingleInstanceForMultiCreation5]]
* [[Template:Layout:OttrDefaultLayout]]
== Pre Definded OTTR Templates ==
* [[Template:ottr:Triple]]
* [[Template:ax:SubClassOf]]
* [[Template:ax:Type]]</text>
<sha1>g2ipnzcxc01codwt2398vbpdf5w05jg</sha1>
</revision>
</page>
<page>
<title>Ottr:Feature Representation</title>
<ns>0</ns>
<id>485</id>
<revision>
<id>3148</id>
<parentid>3147</parentid>
<timestamp>2021-09-21T09:55:19Z</timestamp>
<contributor>
<username>Florian Schröder</username>
<id>23</id>
</contributor>
<model>wikitext</model>
<format>text/x-wiki</format>
<text xml:space="preserve" bytes="12412">An Overview of how different OTTR Features are represented in the MediaWiki/Semantic MediaWiki Syntax.
== Prefix ==
Only writes subobject on a prefix page, not on usual pages. In Template:ottr:Prefix:
<pre>{{#subobject: |iri={{#replace:{{#replace:'&lt;iri&gt;'|&lt;|}}|&gt;|}} |namespace=&lt;namespace&gt;|subobject-category=OTTR-Prefix}}</pre>
The namespace is the short version.
Displays on the special page: &gt; 1. Prefix: '''prefix''' : ‘&lt;’iri’&gt;’
On other pages (if the prefix is not on the special page):
<blockquote>Prefix '''prefix''' is not defined on page [[Ottr:Ottr:OttrPrefixes|Ottr:OttrPrefixes]]!
</blockquote>
With the check query:
<pre>{{#if:
{{#ask:
[[-Has subobject::Ottr:OttrPrefixes]][[namespace::{{{2}}}]]
|?namespace
|format=list
|link=none
}}
|
|&lt;above_warning_msg&gt;
}}</pre>
== Template Call ==
<pre>{{&lt;template_name&gt;
|&lt;arg_1_representation&gt;
|...
|&lt;arg_N_representation&gt;
|ottr_arg_type_1=&lt;type_representation_arg_1&gt;
|...
|ottr_arg_type_N=&lt;type_representation_arg_N&gt;
|call_occurence=&lt;call_occurence&gt;
|call_depth={{#expr: {{{call_depth}}} + 1}}
}}</pre>
<code>call_occurence</code> is first initialised with <code>{{FULLPAGENAME}}_&lt;additional_pos_info&gt;</code> and call depth with 1.
The <code>ottr_arg_type_X</code> arguments contain a type string with string elements (separated by '''''§''''') that represent a known type the argument.
=== None Arguments ===
Input arguments <code>none</code> and <code>ottr:none</code> are replaced by the empty string and have the type <code>ottr:none</code>.
== Optional Argument Check ==
If a parameter has the option '''?''', it can be none. All other arguments are checked for not <code>none</code> with this expression:
<pre>
{{#iferror: <inner_optional_check>||<the inner template>}}
</pre>
The inner optional check checks for every not optional argument:
<pre>
{{#if: {{{<parameter_position>}}}||<strong class="error">b</strong>}}<inner_optional_check>
</pre>
It does not throw an error or warning, because it is a feature of the ottr language to be a silent template instance if an argument is None, but the template is not allowed to generate its own instances under these conditions.
== Default Value ==
All usages of an argument with a default value in a template have the following format (normally <code>{{{%s|}}}</code>)
<pre>{{#if: {{{&lt;parameter_position&gt;|}}}|{{{&lt;parameter_position&gt;}}}|&lt;default_represenation&gt;}}</pre>
== Blank Node Representation ==
<pre>ottr:blank:{{{call_occurrence}}}_BN-&lt;blank_node_name&gt;</pre>
The blank node name for an anonymous blank node is a number, that increases for every anonymous blank node in a call. The type representation of a blank_node is <code>ottr:blank</code>
== Non Blank Argument Check ==
Check with iferror for error in non blank check and use variable for error msg string:
<pre>
{{#iferror: <inner non blank check>|{{ottr:ErrorMsg|{{#var:ottr_arg_non_blankerror_msg}}|code=3}}|<the inner template>}}
</pre>
Find ottr:blank§ in the type representation of the argument, if so then write variable with error msg, else check other arguments.
<pre>
{{#if: {{#pos:{{{ottr_arg_type_<parameter_position>|}}}|ottr:blank§}}
|{{#vardefine:ottr_arg_non_blankerror_msg|{{#var:ottr_arg_non_blankerror_msg}}Argument %i (%s) is a blank node, but declared as non blank<br/>}}<strong class="error">b</strong>
|
}}<inner non blank check>
</pre>
== Type Restriction Check ==
There is a difference between a hard check of different ottr (literal and iri) types. If they fail they produce an error, but no triples and other template calls. Inferenced types (by category relations) produce only warnings and do not stop the evaluating of the template.
An ottr:none argument is every type.
=== Simple Type Check ===
<pre>{{#iferror:
{{#if: {{{&lt;parameter_position&gt;|}}}
|{{#if: {{#pos:{{{ottr_arg_type_&lt;parameter_position&gt;|}}}|&lt;restricted_type_represenation&gt;§}}
|
|{{#if: {{#pos:{{{ottr_arg_type_%i}}}|xsd:string}}
|{{#if: {{#pos:{{{ottr_arg_type_%i|}}}|%s§}}
|
|&lt;strong class=&quot;error&quot;&gt;b&lt;/strong&gt;
}}
|&lt;strong class=&quot;error&quot;&gt;b&lt;/strong&gt;
}}
}}
|{{ottr:ErrorMsg|Have not found a (simple) type match of the input '{{{&lt;parameter_position&gt;|}}}' for argument &lt;parameter_position&gt; in template '&lt;template_name&gt;' (&lt;restricted_type_represenation&gt;§ in '{{{ottr_arg_type_&lt;parameter_position&gt;|}}}')|code=4}}
|&lt;complex_type_check&gt;
}}
}}</pre>
<code>&lt;restricted_type_represenation&gt;</code> is the reduced type without LUB, NEList is also List and a requested type different to “rdfs:resource”, “xsd:boolean”, “xsd:float”, “xsd:integer” and “xsd:string” is only represented as “ottr:IRI”
=== Complex Type Check ===
Class inheritance in SMW with Categories. For <code>rdfs:type</code>: On Instance page: <code>[[Category:&lt;class_page&gt;]]</code>. For <code>rdf:SubClassOf</code>: On Page <code>Category:&lt;sub_class&gt;</code>: <code>[[Category:&lt;class&gt;]]</code>.
If the requested type is not a simple type, a nested (a more complex) type check is added to the simple type check.
The complex check starts with:
<pre>{{#if:{{#pos:{{{ottr_arg_type_&lt;parameter_position&gt;}}}|ottr:IRI}}|&lt;inner_complex_check&gt;}}</pre>
(Only arguments with <code>ottr:IRI</code> inside the type string of an argument, are checked for complex types)
For every List in the requested type the code checks
1. if the requested List is a “Not-Empty-List” with:
<pre>{{#ifexpr: {{#arraysize:&lt;value_ref&gt;}} = 0
| {{#if: &lt;value_ref&gt;|{{ottr:ErrorMsg|&lt;error_text&gt;|code=7|type=Warning}}|}}
|&lt;inner_complex_check&gt;
}}</pre>
<ol start="2" style="list-style-type: decimal;">
<li>Adds a check for every element in the list:</li></ol>
<pre>{{#loop:type_list_test_&lt;restricted_type_represenation&gt;
|0
|{{#arraysize:&lt;value_ref&gt;}}
|&lt;inner_complex_check&gt;
}}</pre>
<ol start="3" style="list-style-type: decimal;">
<li>Updates the <code>&lt;value_ref&gt;</code> to:</li></ol>
<pre>{{#explode:{{#arrayindex:&lt;value_ref&gt;|{{#var:type_list_test_&lt;restricted_type_represenation&gt;}}}}|;|0}}</pre>
Last, check, dependent on the existence of a LUB restriction, if the most inner iri is listed (as a page) in the category of the requested type:
* LUB:
<pre>{{#ifeq: {{ottr:checkLUBType|&lt;value_ref&gt;|&lt;target_type&gt;}}|NoMatch|&lt;warningMsg&gt;|}}</pre>
* Normal URI:
<pre>{{#ifeq: {{ottr:checkType|&lt;value_ref&gt;|&lt;target_type&gt;}}|NoMatch|&lt;warningMsg&gt;|}}</pre>
Where <code>target_type</code> is the (not replaced by <code>ottr:IRI</code>) most inner requested type.
The Template '''ottr:checkType''' contains:
<pre> {{#ask:[[category:{{{2}}}]][[{{{1}}}]]|default=nomatch|format=list|link=none|mainlabel=-}}</pre>
and '''ottr:checkLUBType''':
</pre>
{{#if: {{#pos:{{#ask:[[{{{1|}}}]]|?Category=|link=none|format=list|mainlabel=-}},|Category:{{ucfirst:{{{2|}}}}}}}|found|NoMatch}}</pre>
=== Some Type Representations ===
The generated type strings for literals (also parsed by the ottr syntax) are:
<pre>
type_to_type_string = {
LiteralType.RDFLIT: "xsd:string§rdfs:resource§",
LiteralType.BOOL: "xsd:boolean§rdfs:resource§",
LiteralType.INTEGER: "xsd:integer§xsd:float§rdfs:resource§",
LiteralType.DECIMAL: "xsd:float§rdfs:resource§",
}</pre>
RDFLIT is the string type. Also Type Hints via <code>&quot;some string text&quot;&quot;^^&lt;typeHint&gt;</code> are also mapped by the above dictionary, with the keys:
<pre>
class LiteralType:
INTEGER = "xsd:integer"
DECIMAL = "xsd:float"
BOOL = "xsd:boolean"
RDFLIT = "xsd:string"
</pre>
If they are equal.
The type string for an IRI is:
<pre>"ottr:IRI§rdfs:resource§"</pre>
The type of a list is calculated by a template (<code>ottr:ListType</code>) with the content:
<pre>{{#if: {{{1|}}}
|{{#arraydefine:mykey|{{{1}}}|,}}
{{#arraydefine:incommonarray|{{#explode:{{#arrayindex:mykey|0}}|;|1}}|§}}
{{#loop: idx
|0
|{{#arraysize:mykey}}
|{{#arraydefine: i_array|{{#explode:{{#arrayindex:mykey|{{#var:idx}}}}|;|1}}|§}}
{{#arrayintersect:incommonarray|incommonarray|i_array}}
}}
{{#loop: idx
|0
|{{#arraysize:incommonarray}}
|{{#if: {{#arrayindex:incommonarray|{{#var:idx}}}}
|List&lt;{{#arrayindex:incommonarray|{{#var:idx}}}}&gt;§
|
}}
}}
{{#arrayreset:mykey|incommonarray|i_array}}
|
}}</pre>
It calculates the intersection of all types of all elements in a list.
== Lists ==
A list is an array.
The value and the type of an element of a list is separated by <code>;</code>. Elements in a list are separated by <code>,</code>.
<pre>{{#arraydefine:&lt;list_key&gt;|&lt;list_repr&gt;|,}}</pre>
The list_key is <code>&lt;call_occurence&gt;_listkey_&lt;list_counter&gt;</code> The type of a list is derived from the types of the elements, with an intersection of all type strings. Every result type is than put into <code>List'&lt;'&lt;type&gt;'&gt;'</code>
Elements of an array are accessed by <code>{{#arrayindex: &lt;list_key&gt;|{{#var: &lt;loop_index&gt;}} }}</code> The value of an element with <code>xyz=0</code> and the type with <code>xyz=1</code> in <code>{{#explode:&lt;element_repr&gt;|;|xyz}}</code>
A template call with only one list expand is handled in the following way:
<pre>{{#loop: {{ottr:idx_key|{{{call_occurrence}}}_%i|0}}
| 0
| {{#arraysize:&lt;list_key&gt;}}
|{{&lt;template_name&gt;&lt;argument_string&gt;}}
}}</pre>
=== Cross ===
For every list a loop. Nesting loops inside <code>%%s</code>.
<pre>{{#loop:&lt;idx_key&gt; | 0 | {{#arraysize:&lt;list_key&gt;}}|%%s}}</pre>