-
Notifications
You must be signed in to change notification settings - Fork 82
/
docs
971 lines (828 loc) · 91.5 KB
/
docs
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
<!DOCTYPE html>
<html lang="en" xml:lang="en" xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta charset="utf-8" />
<title>dokieli documentation</title>
<meta content="width=device-width, initial-scale=1" name="viewport" />
<link href="media/css/basic.css" media="all" rel="stylesheet" title="Basic" />
<link href="media/css/lncs.css" media="all" rel="stylesheet alternate" title="LNCS" />
<link href="media/css/acm.css" media="all" rel="stylesheet alternate" title="ACM" />
<link href="https://www.w3.org/StyleSheets/TR/2021/base.css" rel="stylesheet alternate" media="all" title="W3C-Base" />
<link href="media/css/dokieli.css" media="all" rel="stylesheet" />
<script src="https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.2/MathJax.js?config=TeX-MML-AM_HTMLorMML"></script>
<script src="scripts/dokieli.js"></script>
</head>
<body about="" prefix="rdf: http://www.w3.org/1999/02/22-rdf-syntax-ns# rdfs: http://www.w3.org/2000/01/rdf-schema# owl: http://www.w3.org/2002/07/owl# xsd: http://www.w3.org/2001/XMLSchema# rdfa: http://www.w3.org/ns/rdfa# dcterms: http://purl.org/dc/terms/ dctypes: http://purl.org/dc/dcmitype/ foaf: http://xmlns.com/foaf/0.1/ pimspace: http://www.w3.org/ns/pim/space# skos: http://www.w3.org/2004/02/skos/core# prov: http://www.w3.org/ns/prov# mem: http://mementoweb.org/ns# qb: http://purl.org/linked-data/cube# schema: http://schema.org/ void: http://rdfs.org/ns/void# rsa: http://www.w3.org/ns/auth/rsa# cert: http://www.w3.org/ns/auth/cert# wgs: http://www.w3.org/2003/01/geo/wgs84_pos# bibo: http://purl.org/ontology/bibo/ sioc: http://rdfs.org/sioc/ns# doap: http://usefulinc.com/ns/doap# dbr: http://dbpedia.org/resource/ dbp: http://dbpedia.org/property/ sio: http://semanticscience.org/resource/ opmw: http://www.opmw.org/ontology/ deo: http://purl.org/spar/deo/ doco: http://purl.org/spar/doco/ cito: http://purl.org/spar/cito/ fabio: http://purl.org/spar/fabio/ oa: http://www.w3.org/ns/oa# as: https://www.w3.org/ns/activitystreams# ldp: http://www.w3.org/ns/ldp# solid: http://www.w3.org/ns/solid/terms# acl: http://www.w3.org/ns/auth/acl# earl: http://www.w3.org/ns/earl# spec: http://www.w3.org/ns/spec# odrl: http://www.w3.org/ns/odrl/2/ dio: https://w3id.org/dio# rel: https://www.w3.org/ns/iana/link-relations/relation#">
<main>
<article about="">
<h1 property="schema:name">dokieli documentation</h1>
<details>
<summary>More details about this document</summary>
<dl id="document-identifier">
<dt>Identifier</dt>
<dd><a href="https://dokie.li/docs" rel="owl:sameAs">https://dokie.li/docs</a></dd>
</dl>
<dl id="document-published">
<dt>Published</dt>
<dd><time content="2017-07-15T00:00:00Z" datatype="xsd:dateTime" datetime="2017-07-15T00:00:00Z" property="schema:datePublished">2017-07-15</time></dd>
</dl>
<dl id="document-modified">
<dt>Modified</dt>
<dd><time content="2024-07-09T00:00:00Z" datatype="xsd:dateTime" datetime="2024-07-09T00:00:00Z" property="schema:dateModified">2024-07-09</time></dd>
</dl>
<dl id="document-license">
<dt>License</dt>
<dd><a href="https://creativecommons.org/licenses/by/4.0/" rel="schema:license" title="Creative Commons Attribution 4.0 Unported">CC BY 4.0</a></dd>
</dl>
<dl id="document-feedback">
<dt>Feedback</dt>
<dd><a href="https://github.com/linkeddata/dokieli" rel="doap:repository">GitHub linkeddata/dokieli</a> (<a href="https://github.com/lineddata/dokieli/pulls">pull requests</a>, <a href="https://github.com/lineddata/dokieli/issues/new">new issue</a>, <a href="https://github.com/lineddata/dokieli/issues" rel="doap:bug-database">open issues</a>)</dd>
</dl>
<dl id="document-language">
<dt>Language</dt>
<dd><span content="en" lang="" property="dcterms:language" xml:lang="">English</span></dd>
</dl>
<dl id="document-type">
<dt>Document Type</dt>
<dd><a href="http://schema.org/Article" rel="rdf:type">Article</a></dd>
</dl>
</details>
<div datatype="rdf:HTML" id="content" property="schema:description">
<section id="abstract">
<h2>Abstract</h2>
<div datatype="rdf:HTML" property="schema:abstract">
<p>This documentation is intended to help brave developers and authors. It explains dokieli's principles, architectural and design patterns.</p>
</div>
</section>
<nav id="table-of-contents"><h2>Contents</h2><div><ol class="toc"><li data-id="abstract"><a href="#abstract">Abstract</a></li><li data-id="document-status"><a href="#document-status">Document Status</a></li><li data-id="principles"><a href="#principles">Principles</a></li><li data-id="structure-and-semantics"><a href="#structure-and-semantics">Structure and Semantics</a><ol><li data-id="dokieli-documents"><a href="#dokieli-documents">dokieli documents</a></li><li data-id="html-patterns"><a href="#html-patterns">HTML patterns</a><ol><li data-id="html-article"><a href="#html-article">Article</a></li><li data-id="html-annotation"><a href="#html-annotation">Annotation</a></li><li data-id="html-notification"><a href="#html-notification">Notification</a></li></ol></li></ol></li><li data-id="user-interface"><a href="#user-interface">User interface</a><ol><li data-id="document-modes"><a href="#document-modes">Document modes</a></li><li data-id="features"><a href="#features">Features</a></li></ol></li><li data-id="accessibility-usability-inclusion"><a href="#accessibility-usability-inclusion">Accessibility, Usability, and Inclusion</a><ol><li data-id="accessibility-statement"><a href="#accessibility-statement">Accessibility Statement</a><ol><li data-id="accessibility-measures-to-support-accessibility"><a href="#accessibility-measures-to-support-accessibility">Measures to support accessibility</a></li><li data-id="accessibility-conformance-status"><a href="#accessibility-conformance-status">Conformance status</a></li><li data-id="accessibility-feedback"><a href="#accessibility-feedback">Feedback</a></li><li data-id="accessibility-technical-specifications"><a href="#accessibility-technical-specifications">Technical specifications</a></li><li data-id="accessibility-assessment-approach"><a href="#accessibility-assessment-approach">Assessment approach</a></li></ol></li><li data-id="authoring-accessibility"><a href="#authoring-accessibility">Authoring accessibility</a><ol><li data-id="authoring-tool-user-interface-accessibility"><a href="#authoring-tool-user-interface-accessibility">Authoring tool user interface accessibility</a></li><li data-id="support-for-producing-accessible-content"><a href="#support-for-producing-accessible-content">Support for producing accessible content</a></li></ol></li></ol></li><li data-id="http-operations"><a href="#http-operations">HTTP operations</a></li><li data-id="authentication"><a href="#authentication">Authentication</a></li><li data-id="storage"><a href="#storage">Storage</a></li><li data-id="web-extension"><a href="#web-extension">Web Extension</a></li><li data-id="development"><a href="#development">Development</a></li></ol></div></nav>
<section id="principles" inlist="" rel="schema:hasPart" resource="#principles">
<h2 property="schema:name">Principles</h2>
<div datatype="rdf:HTML" property="schema:description">
<p>Towards improving the <em>write</em> dimension of the <em>read-write</em> Web, dokieli's design subscribes to the following principles: freedom of expression, interoperability, decentralisation, evolvability, universal access, separation of concerns, <code>█ + █ > = █ █</code>.</p>
</div>
</section>
<section id="structure-and-semantics" inlist="" rel="schema:hasPart" resource="#structure-and-semantics">
<h2 property="schema:name">Structure and Semantics</h2>
<div datatype="rdf:HTML" property="schema:description">
<p>This section describes dokieli's practices, and offers some guidelines for developers and authors that would like to maintain uniformity in what they create. Consumers of dokieli should not treat the information here as a <em>profile</em>, or as a yet another super or subset of HTML+RDFa when they author or build new functionality. Creating articles, annotations, and notifications in dokieli is intended to be done through its UI, where it takes care of majority of the semantic content generation. The information here however can be useful for authors that would like to combine hand coding with the functionality that dokieli's UI provides. Takeaway what you find useful, there is no proprietary lock-in here.</p>
<p id="separation-of-concerns">dokieli adopts <cite>progressive enhancement</cite> strategy for the structural, presentational, and behavioural layers to allow content and base functionality to be accessible through different media and devices. The content in HTML+RDFa that dokieli produces <em>is</em> accessible (readable) without requiring any CSS or JavaScript, ie. text-browser safe. Breaking this "rule" in future development should be considered an anti-pattern (or a bug) in dokieli.</p>
<p id="serialisations">dokieli can serialise articles, annotations, and notifications in HTML+RDFa, Turtle, and JSON-LD, depending on server content-negotiation. Articles are represented in HTML+RDFa so that information is usable by both humans and machine consumers while maintaining lowest requirements for publishing, eg. a single URL with full payload in HTML+RDFa can be accessible from any HTTP server. No additional requirements necessary from clients (eg. JavaScript support and enabled) or servers (eg. additional RDF based content-negotiation). For annotations and notifications, dokieli first meets interoperability requirements (for protocols and vocabularies), and remains flexible about the serialisation that servers prefer. Similarly for consuming content, it can work with any of the serialisations as mentioned.</p>
<p id="human-machine-readable">dokieli takes the approach of having all human-visible content in HTML, and all structured statements be made in context of their content in RDFa. This is optimal in avoiding data duplication in the same document which happens to be the case with the other serialisations in RDF. The approach also helps to avoid the creation and usage of multiple data islands, ie. separately for humans and machines. It is efficient in that it has no dependency on JavaScript in order to make the hidden machine-readable content be consumable from a human user interface. One exception to this rule is allowing authors to use the <cite>Embed Data</cite> feature to include Turtle, JSON-LD, or TriG data blocks for alternative reasons.</p>
<section id="dokieli-documents" inlist="" rel="schema:hasPart" resource="#dokieli-documents">
<h3 property="schema:name">dokieli documents</h3>
<div datatype="rdf:HTML" property="schema:description">
<p>Is there such thing as a "dokieli" document? Must there be?</p>
<dl>
<dt>Article</dt>
<dd>An article may contain RDF classes like <samp>schema:CreativeWork sioc:Post prov:Entity schema:Article</samp>, otherwise, there is no unique data that would indicate that it is a "dokieli" document. If the HTML+RDFa representation includes dokieli.js and the DOM is ready, the <code>DO</code>: <code>Object { C: {…}, U: {…} }</code> will be available.</dd>
<dt>Annotation</dt>
<dd>An annotation has the <code>oa:Annotation</code> class. It is possible to know that the article was rendered by dokieli: <code>?s oa:renderedVia <https://dokie.li/></code>, and we can assume that the annotation was created by it as well. This is not strictly true since that property could have been put there by something else. Annotations represented in HTML+RDFa do not include dokieli.js.</dd>
<dt>Notification</dt>
<dd>A notification may have one of the following classes: <code>as:Announce</code>, <code>as:Like</code>, <code>as:Dislike</code>, <code>as:Relationship</code>. Notifications represented in HTML+RDFa do not include dokieli.js.</dd>
</dl>
</div>
</section>
<section id="html-patterns" inlist="" rel="schema:hasPart" resource="#html-patterns">
<h3 property="schema:name">HTML patterns</h3>
<div datatype="rdf:HTML" property="schema:description">
<p>One of the goals of dokieli is not to impose arbitrary restrictions on type of nodes as well as the order they should be in HTML+RDFa. It has its own design patterns. It is an ongoing work to make dokieli as flexible as it can be on what it can consume. Ultimately, well-formed and valid HTML - along with accompanying RDFa, Turtle, JSON-LD, TriG etc - is the only requirement here. Take what you like:</p>
<dl>
<dt id="html-markup-syntax">Markup syntax</dt>
<dd>HTML5 <cite><a href="https://www.w3.org/TR/html-polyglot/" rel="cito:citesAsAuthority">Polyglot Markup</a></cite> is used to ensure that when content is processed or served as HTML or XHTML (<code>text/html</code>, <code>application/xhtml+xml</code>), they can generally be used in both HTML and XML ecosystems without further intervention. See also <var>getDocument</var> (dokieli.js) for details on DOM normalisation.</dd>
<dt id="html-identifiers">Identifiers</dt>
<dd>Unique identifiers (<code>@id</code>) may be placed on any element. Identifiers are auto-generated by normalising some input eg. <code>section</code>s use their heading's text content as input, <code>table</code>s from <code>caption</code>. Anything of importance should have an identifier, and aimed to be included for common patterns out of the box. <code>@id</code> values are reused in RDFa. See also <var>generateAttributeId</var> (dokieli.js) and its application in different places.</dd>
<dt id="html-outline">Outline</dt>
<dd>
<ul>
<li><code>title</code> is used.</li>
<li><code>main > article</code> (querySelector) is considered to be the location of the primary content.</li>
<li><code>h1</code> is typically the first element node after <code>main > article</code></li>
<li>There is a resource type, eg. <code>schema:Article</code> that can be found in <code>main > article</code> which is about the article. <code>body</code> may contain broad classes.</li>
</ul>
</dd>
<dt id="html-section">Section</dt>
<dd>Sectioning is declared with <code>section</code> and typically have a heading, eg. <code>h2</code> as its first child. Subsections may appear as a child of parent <code>section</code>, or as a child of <code>div</code> (which is a child of parent <code>section</code>), ie. <code>section section</code> or <code>section div section</code>. The headings of subsections are enumerated eg. <code>section h2</code> would have a subsection with <code>section h3</code>. Sections <code>id</code>s and heading text are used to dynamically build the table of contents.
<figure class="listing" id="html-section-source" rel="schema:hasPart" resource="#html-section-source">
<pre about="#html-section-source" lang="" property="schema:description" typeof="fabio:Script" xml:lang=""><code class="highlight-section"><section></code>
<samp class="highlight-h2"> <h2></samp>
<code class="highlight-div"> <div></code>
<code class="highlight-section"> <section></code>
<samp class="highlight-h3"> <h3></samp>
<code class="highlight-div"> <div></code>
<code class="highlight-div"> <div></code>
<code class="highlight-aside"> <aside></code>
<code class="highlight-section"><section></code>
<samp class="highlight-h2"> <h2></samp>
<code class="highlight-section"> <section></code>
<samp class="highlight-h3"> <h3></samp></pre>
<figcaption property="schema:name"><samp class="highlight-h2">h2</samp> and <samp class="highlight-h3">h3</samp> are used for <code class="highlight-section">section</code> titles, <code class="highlight-div">div</code> as a typical wrapper (eg. for <em>descriptions</em>), as well as to contain further sub-sectioned content.</figcaption>
</figure>
</dd>
<dt id="html-aside">Aside</dt>
<dd><code>aside</code>s can technically appear anywhere, but tend to appear as the last element node in <code>section</code>, eg. for related content, footnotes. If the <code>aside</code> is introduced to the DOM via JavaScript for like annotations, they have a similar structure to <code>section</code>.</dd>
<dt id="html-div">Division</dt>
<dd><code>div</code>s within <code>section</code> are used to wrap a block of arbitrary markup and content. See also RDFa below.</dd>
<dt id="html-figure">Figure</dt>
<dd><code>figure</code>s typically have <code>figcaptions</code> for things like <code>audio</code>, <code>canvas</code>, <code>iframe</code>, <code>img</code>, <code>object</code>, <code>pre</code>, <code>video</code>, <code>math</code>. For code scripts, <code>figure class="listing"</code> is used, and <code>pre</code> for the code itself with <code>code</code> The <code>listing</code> class is intended to have a collection of figures, which could also have a unique presentation, for example with line numbers or have its caption be prefixed with <q>Listing</q> and counter.
<figure class="listing" id="html-figure-listing" rel="schema:hasPart" resource="#html-figure-listing">
<pre about="#html-figure-listing" lang="" property="schema:description" typeof="fabio:Script" xml:lang=""><code class="highlight-section"><section></code>
<samp class="highlight-h2"> <h2></samp>
<code class="highlight-div"> <div></code>
<code class="highlight-section"> <section></code></pre>
<figcaption>Snippet of <a href="#html-section-source">section source</a> code</figcaption>
</figure>
<table id="comparison-of-systems">
<caption>Comparison of systems</caption>
<thead>
<tr>
<th></th>
<th>d<sub>1</sub></th>
<th>d<sub>2</sub></th>
<th>d<sub>3</sub></th>
<th>m<sub>1</sub></th>
</tr>
</thead>
<tbody>
<tr><th>Foo</th><td>m</td><td>o</td><td>n</td><td>1</td></tr>
<tr><th>Bar</th><td>k</td><td>e</td><td>y</td><td>2</td></tr>
<tr><th>Baz</th><td>!</td><td>@</td><td>#</td><td>3</td></tr>
</tbody>
<tfoot>
<tr><td colspan="4">Table columns list the dimensions: d<sub>1</sub>, d<sub>2</sub>, d<sub>3</sub>, and the measure: m<sub>1</sub>.</td></tr>
</tfoot>
</table>
</dd>
<dt id="html-math">Math</dt>
<dd>For mathematical equations <code>figure class="equation"</code> can be used to hint at an equation display. <cite><a href="https://www.w3.org/TR/MathML/">MathML</a></cite> base equation with <code><math xmlns="http://www.w3.org/1998/Math/MathML"></code> root can be included here (see also source). Alternatively, if <cite><a href="https://www.mathjax.org/">MathJax</a></cite> JavaScript is available in the document, <cite><a href="https://en.wikibooks.org/wiki/LaTeX/Mathematics">(La)TeX</a></cite>, eg. <samp>\lim_{x \to \infty} \exp(-x) = 0</samp> and <cite><a href="http://asciimath.org/">ASCIIMath</a></cite>, eg. <samp>sum_(i=1)^n i^3=((n(n+1))/2)^2</samp>, syntaxes can be input within the authoring mode (via <cite>Edit</cite>).
<figure class="equation" typeof="doco:FormulaBox">
<math xmlns="http://www.w3.org/1998/Math/MathML">
<mtable>
<mtr>
<mtd>
<munder>
<mi>lim</mi>
<mrow>
<mi>n</mi>
<mo>→</mo>
<mo>∞</mo>
</mrow>
</munder>
<mi>x</mi>
<mo>=</mo>
<mn>0</mn>
</mtd>
</mtr>
</mtable>
</math>
</figure>
</dd>
<dt id="html-embed-turtle-json-ld-trig">Embedding Turtle, JSON-LD, and TriG</dt>
<dd>Turtle, JSON-LD, and TriG syntaxes are placed within respective <code>script</code> blocks in <code>head</code> eg. <code><script id="meta-json-ld" type="application/ld+json" title="JSON-LD"></script></code>. Data is enclosed in <code>CDATA</code> sections. This pattern is detected, visible and editable from <cite>Embed Data</cite> in <i class="fa fa-bars"></i> <a href="#dokieli-menu">dokieli menu</a>. See also <var>showEmbedData</var> (dokieli.js).</dd>
<dt id="html-css">CSS</dt>
<dd>Multiple stylesheets can be included with <code>@media</code>, and when accompanied with <code>@title</code>, some user-agents can provide options for the user to switch between them, as well as from the <i class="fa fa-bars"></i> <a href="#dokieli-menu">dokieli menu</a>, eg. <pre><!-- Primary stylesheet -->
<code><link href="media/css/basic.css" media="all" rel="stylesheet" title="Basic" /></code>
<!-- Alternate stylesheet -->
<code><link href="media/css/acm.css" media="all" rel="stylesheet alternate" title="ACM" /></code>
<!-- Applied by default-->
<code><link href="https://dokie.li/media/css/dokieli.css" media="all" rel="stylesheet" /></code></pre> See also <var>showViews</var> (dokieli.js).</dd>
<dt id="html-rdfa">RDFa</dt>
<dd>dokieli can consume and produce <cite><a href="https://www.w3.org/TR/rdfa-core/">RDFa Core 1.1</a></cite> syntax.</dd>
<dd>To preserve the order of content, <code>@inlist</code> is used eg. <code><section inlist=""</code>, <code><dd id="Sarven-Capadisli" inlist="" rel="bibo:authorList" resource="http://csarven.ca/#i"></code>.</dd>
<dd>A <code>section</code>s <code>@id</code> value is used as part of <code>section</code>'s <code>@resource</code> as a fragment, eg. <code><section id="introduction" rel="schema:hasPart" resource="#introduction"></code>. This allows the same identifier to be used for humans and machines, the value is derived from normalising its heading value as mentioned earlier.</dd>
<dd>Relating parts is done with <code>rel="schema:hasPart"</code>, eg. sections with subsection: <pre><code><section id="structure-and-semantics" inlist="" rel="schema:hasPart" resource="#structure-and-semantics"></code>
<code> <section id="html-patterns" inlist="" rel="schema:hasPart" resource="#html-patterns"></code></pre>
</dd>
<dd><code>div</code>s are used to hold a block of HTML markup and types of content together eg. <code><div datatype="rdf:HTML" property="schema:description" resource="#introduction" typeof="deo:Introduction"></code> makes it possible to declare that it contains HTML markup, and describes an introductory text.</dd>
<dd>Some of the prefixes (<code>@prefix</code>) on the <code>body</code> element are defined in the <cite><a href="https://www.w3.org/2011/rdfa-context/rdfa-1.1.html">RDFa Core Initial Context</a></cite>. These prefixes are defined in dokieli for the purpose of being compact, robust, and to minimise potential errors for consumers.</dd>
</dl>
<div class="note">
<h4>Note</h4>
<div>
<p>There is a <em>work in progress</em> to have a distribution version of dokeli, requiring only <samp>dokieli.css</samp> and <samp>dokieli.js</samp> in templates.</p>
</div>
</div>
<p id="html-charset">Servers should use <code>UTF-8</code> character encoding in their HTTP responses to articles, annotations, and notifications. <code><meta charset="utf-8" /></code> is used in HTML.</p>
<section id="html-article" inlist="" rel="schema:hasPart" resource="#html-article">
<h4 property="schema:name">Article</h4>
<div property="schema:description">
<p>See also <var>createNoteDataHTML</var> (dokieli.js)</p>
<figure class="listing" id="#html-article-source" rel="schema:hasPart" resource="#html-article-source">
<pre about="#html-article-source" lang="" property="schema:description" typeof="fabio:Script" xml:lang=""><code><!DOCTYPE html></code>
<code><html lang="en" xml:lang="en" xmlns="http://www.w3.org/1999/xhtml"></code>
<code> <head></code>
<code> <meta charset="utf-8" /></code>
<code> <title></title></code>
<code> <meta content="width=device-width, initial-scale=1" name="viewport" /></code>
<code> <link href="https://dokie.li/media/css/basic.css" media="all" rel="stylesheet" title="Basic" /></code>
<code> <link href="https://dokie.li/media/css/dokieli.css" media="all" rel="stylesheet" /></code>
<code> <script src="https://dokie.li/scripts/dokieli.js"></script></code>
<code> </head></code>
<code></code>
<code> <body about="" prefix="rdf: http://www.w3.org/1999/02/22-rdf-syntax-ns# rdfs: http://www.w3.org/2000/01/rdf-schema# owl: http://www.w3.org/2002/07/owl# xsd: http://www.w3.org/2001/XMLSchema# dcterms: http://purl.org/dc/terms/ dctypes: http://purl.org/dc/dcmitype/ foaf: http://xmlns.com/foaf/0.1/ pimspace: http://www.w3.org/ns/pim/space# skos: http://www.w3.org/2004/02/skos/core# prov: http://www.w3.org/ns/prov# mem: http://mementoweb.org/ns# qb: http://purl.org/linked-data/cube# schema: http://schema.org/ void: http://rdfs.org/ns/void# rsa: http://www.w3.org/ns/auth/rsa# cert: http://www.w3.org/ns/auth/cert# wgs: http://www.w3.org/2003/01/geo/wgs84_pos# bibo: http://purl.org/ontology/bibo/ sioc: http://rdfs.org/sioc/ns# doap: http://usefulinc.com/ns/doap# dbr: http://dbpedia.org/resource/ dbp: http://dbpedia.org/property/ sio: http://semanticscience.org/resource/ opmw: http://www.opmw.org/ontology/ deo: http://purl.org/spar/deo/ doco: http://purl.org/spar/doco/ cito: http://purl.org/spar/cito/ fabio: http://purl.org/spar/fabio/ oa: http://www.w3.org/ns/oa# as: https://www.w3.org/ns/activitystreams# ldp: http://www.w3.org/ns/ldp# solid: http://www.w3.org/ns/solid/terms# acl: http://www.w3.org/ns/auth/acl# dio: https://w3id.org/dio# rel: https://www.w3.org/ns/iana/link-relations/relation#" typeof="schema:CreativeWork prov:Entity"></code>
<code> <main></code>
<code> <article about="" typeof="schema:Article"></code>
<code></code>
<code> </article></code>
<code> </main></code>
<code> </body></code>
<code></html></code></pre>
<figcaption property="schema:name">Example article HTML</figcaption>
</figure>
<p>The subject of the following statements may be anywhere in a document. They tend to give some provenance level information and intended to bring more context and attract reuse of the document in different ways.</p>
<pre id="html-document-identifier"><code><dl id="document-identifier"></code>
<code> <dt>Identifier</dt></code>
<code> <dd><a href="http://csarven.ca/dokieli-rww" rel="owl:sameAs">http://csarven.ca/dokieli-rww</a></dd></code>
<code></dl></code></pre>
<p>The <code>owl:sameAs</code> indirectly gives this article, ie. any copy, an identifier. The identifier is typically where an article was originally made accessible from, so having this by default for copy distribution helps to keep its connection to source. </p>
<pre id="html-document-inbox"><code><dl id="document-inbox"></code>
<code> <dt>Notifications Inbox</dt></code>
<code> <dd><a href="https://linkedresearch.org/inbox/csarven.ca/dokieli-rww/" rel="ldp:inbox">inbox/</a></dd></code>
<code></dl></code></pre>
<p><code>ldp:inbox</code> relation gives an article its own Inbox where it can receive notifications about eg. annotations or activities relevant to an article. The notifications can be consumed by applications to offer additional content and interactive possibilities. dokieli can both send and consume notifications by way of discovering an article's inbox. Notifications are created for activities like announcements, creating, (dis)liking, and consumed in order to be displayed in context of available content. The protocol to send and consume notifications in dokieli uses <cite><a href="https://www.w3.org/TR/ldn/">Linked Data Notifications</a></cite>.</p>
<pre id="html-document-annotation-service"><code><dl id="document-annotation-service"></code>
<code> <dt>Annotation Service</dt></code>
<code> <dd><a href="https://linkedresearch.org/annotation/csarven.ca/dokieli-rww/" rel="oa:annotationService">annotation/</a></dd></code>
<code></dl></code></pre>
<p>An article may refer to an annotation service (<code>oa:annotationService</code>) that conforms to the <cite><a href="https://www.w3.org/TR/annotation-protocol/">Web Annotation Protocol</a></cite>. See also <var>DO.C.AnnotationService</var> in <code>dokieli.js</code>.</p>
<pre id="html-document-in-reply-to"><code><dl id="document-in-reply-to"></code>
<code> <dt>In Reply To</dt></code>
<code> <dd><a href="https://linkedresearch.org/calls" rel="as:inReplyTo">Call for Linked Research</a></dd></code>
<code></dl></code></pre>
<p>If an article is a reply to objects(s), it can have a property like <code>as:inReplyTo</code>.</p>
<pre id="html-document-published-modified"><code><dl id="document-published"></code>
<code> <dt>Published</dt></code>
<code> <dd><time content="2017-02-27T00:00:00Z" datatype="xsd:dateTime" datetime="2017-02-27T00:00:00Z" property="schema:datePublished">2017-02-27</time></dd></code>
<code></dl></code>
<code></code>
<code><dl id="document-modified"></code>
<code> <dt>Modified</dt></code>
<code> <dd><time content="2017-03-12T00:00:00Z" datatype="xsd:dateTime" datetime="2017-03-12T00:00:00Z" property="schema:dateModified">2017-03-18</time></dd></code>
<code></dl></code></pre>
<p>Dates, you know.. kinda useful. The example above duplicates the ISO date in <code>@content</code> and <code>@datetime</code>, but only one needs to be there, given that there parsers for different RDFa versions.</p>
<pre id="html-document-license-rights"><code><dl id="document-license"></code>
<code> <dt>License</dt></code>
<code> <dd><a href="https://creativecommons.org/licenses/by/4.0/" rel="schema:license" title="Creative Commons Attribution 4.0 Unported">CC BY 4.0</a></dd></code>
<code></dl></code></pre>
<p>Nice to declare a license or rights to signal under what conditions the document may be reused, reshared or remixed, eg. via <cite><a href="https://creativecommons.org/">Creative Commons</a></cite> license. Articles and notifications tend to use <code>schema:license</code> and annotations use <code>dcterms:rights</code> (given <cite><a href="https://www.w3.org/TR/annotation-vocab/">Web Annotation Vocabulary</a></cite>).</p>
<pre id="html-document-derived-from-on"><code><dl id="document-derived-from"></code>
<code> <dt>Derived From</dt<</code>
<code> <dd><a href="https://dokie.li/" rel="prov:wasDerivedFrom">https://dokie.li/</a></dd></code>
<code></dl></code>
<code></code>
<code><dl id="document-derived-on"></code>
<code> <dt>Derived On</dt></code>
<code> <dd><time datetime="2017-08-06T00:29:45.342Z">2017-08-06T00:29:45.342Z</time></dd></code>
<code></dl></code></pre>
<p>If a document is derived from another using the <cite>Save As</cite> operation, derived from and derived on information is declared.</p>
<p>The markup for an anonymous profile is like:</p>
<pre id="html-profile-anonymous"><code><span typeof="schema:Person">Lunatic Scholar</span></code></pre>
<p>The markup for a WebID profile including their name:</p>
<pre id="html-profile-iri-name"><code><span about="http://csarven.ca/#i" property="schema:name">Sarven Capadisli</span></code></pre>
<p>If they have an image:</p>
<pre id="html-profile-image"><code><img alt="" height="48" rel="schema:image" src="http://csarven.ca/media/images/sarven-capadisli.jpg" width="48" /></code></pre>
<p>Progressively described name, image, and URL is useful in templates:</p>
<pre id="html-profile-iri-name-image-enhanced"><code><span about="http://csarven.ca/#i" typeof="schema:Person"><img alt="" height="48" rel="schema:image" src="http://csarven.ca/media/images/sarven-capadisli.jpg" width="48" /> <a href="http://csarven.ca/" rel="schema:url"><span about="http://csarven.ca/#i" property="schema:name">Sarven Capadisli</span></a></span></code></pre>
<p>Alternatively applying the DRY principle:</p>
<pre id="html-profile-iri-name-image-dry"><code><a about="http://csarven.ca/#i" href="http://csarven.ca/" property="schema:name" rel="schema:url" typeof="schema:Person">Sarven Capadisli</a></code></pre>
<p>If they are one of the authors of a document, the profile can be wrapped like:</p>
<pre id="html-profile-author"><code><dd id="Sarven-Capadisli" inlist="" rel="bibo:authorList" resource="http://csarven.ca/#i"><span about="" rel="schema:creator schema:publisher schema:author"><!-- profile --></span></dd></code></pre>
<p>See also <var>getUserHTML</var> (dokieli.js)</p>
</div>
</section>
<section id="html-annotation" inlist="" rel="schema:hasPart" resource="#html-annotation">
<h4 property="schema:name">Annotation</h4>
<div property="schema:description">
<p>Annotations have their own URL, fetched, parsed, and then introduced into the DOM. They are normally appended at the bottom of a node (<code>section</code>) in which the annotation has a reference to. It is not required to introduce all of the annotation content into the DOM, nor all of it has to be human-visible. This is a run-time inclusion and typically included within <code><aside class="note do"></aside></code>. Write operations like <cite>Save</cite>, <cite>Save As</cite>, <cite>Export</cite> will exclude this (<code>class~="do"</code>) when it normalises the DOM to HTML.</p>
<p>Currently dokieli uses <cite><a href="https://www.w3.org/TR/annotation-vocab/#replying">oa:replying</a></cite>, <cite><a href="https://www.w3.org/TR/annotation-vocab/#commenting">oa:commenting</a></cite>, <cite><a href="https://www.w3.org/TR/annotation-vocab/#describing">oa:describing</a></cite>, <cite><a href="https://www.w3.org/TR/annotation-vocab/#assessing">oa:assessing</a></cite>, <cite><a href="https://www.w3.org/TR/annotation-vocab/#bookmarking">oa:bookmarking</a></cite> for <em>motivations</em>, and <cite><a href="https://www.w3.org/TR/annotation-vocab/#describing">oa:describing</a></cite> and <cite><a href="https://www.w3.org/TR/annotation-vocab/#tagging">oa:tagging</a></cite> for annotation <em>purpose</em>.</p>
<p>See also <var>createNoteDataHTML</var> (dokieli.js)</p>
<p>Here is an annotation resource at <a href="https://linkedresearch.org/annotation/csarven.ca/dokieli-rww/b6738766-3ce5-4054-96a9-ced7f05b439f">https://linkedresearch.org/annotation/csarven.ca/dokieli-rww/b6738766-3ce5-4054-96a9-ced7f05b439f</a> with all information human-visible and machine-readable (HTML+RDFa):</p>
<figure id="html-annotation-view">
<object data="https://linkedresearch.org/annotation/csarven.ca/dokieli-rww/b6738766-3ce5-4054-96a9-ced7f05b439f" height="680" type="text/html" width="100%"></object>
<figcaption>A reply Web Annotation with replying motivation</figcaption>
</figure>
<p>Its source:</p>
<figure class="listing" id="html-annotation-source" rel="schema:hasPart" resource="#html-annotation-source">
<pre about="#html-annotation-source" lang="" property="schema:description" typeof="fabio:Script" xml:lang=""><code><!DOCTYPE html></code>
<code><html lang="en" xml:lang="en" xmlns="http://www.w3.org/1999/xhtml"></code>
<code> <head></code>
<code> <meta charset="utf-8" /></code>
<code> <title>https://linkedresearch.org/annotation/csarven.ca/dokieli-rww/b6738766-3ce5-4054-96a9-ced7f05b439f</title></code>
<code> </head></code>
<code> <body></code>
<code> <main></code>
<code> <article id="b6738766-3ce5-4054-96a9-ced7f05b439f" about="i:" typeof="oa:Annotation" prefix="rdf: http://www.w3.org/1999/02/22-rdf-syntax-ns# schema: http://schema.org/ dcterms: http://purl.org/dc/terms/ oa: http://www.w3.org/ns/oa# as: https://www.w3.org/ns/activitystreams# i: https://linkedresearch.org/annotation/csarven.ca/dokieli-rww/b6738766-3ce5-4054-96a9-ced7f05b439f"></code>
<code> <h1 property="schema:name">Sarven Capadisli <span rel="oa:motivatedBy" resource="oa:replying">replies</span></h1></code>
<code></code>
<code> <dl class="author-name"></code>
<code> <dt>Authors</dt></code>
<code> <dd><span rel="schema:creator"><span about="http://csarven.ca/#i" typeof="schema:Person"><img alt="" height="48" rel="schema:image" src="http://csarven.ca/media/images/sarven-capadisli.jpg" width="48" /> <a href="http://csarven.ca/" rel="schema:url"><span about="http://csarven.ca/#i" property="schema:name">Sarven Capadisli</span></a></span></span></dd></code>
<code> </dl></code>
<code></code>
<code> <dl class="published"></code>
<code> <dt>Published</dt></code>
<code> <dd><a href="https://linkedresearch.org/annotation/csarven.ca/dokieli-rww/b6738766-3ce5-4054-96a9-ced7f05b439f"><time datetime="2017-04-15T21:24:58.293Z" datatype="xsd:dateTime" property="schema:datePublished" content="2017-04-15T21:24:58.293Z">2017-04-15 21:24:58</time></a></code>
<code> </dd></code>
<code> </dl></code>
<code></code>
<code> <dl class="rights"></code>
<code> <dt>Rights</dt></code>
<code> <dd><a href="https://creativecommons.org/licenses/by/4.0/" rel="dcterms:rights" title="Creative Commons Attribution">CC BY 4.0</a></dd></code>
<code> </dl></code>
<code></code>
<code> <dl class="canonical"></code>
<code> <dt>Canonical</dt></code>
<code> <dd about="i:" rel="oa:canonical" resource="urn:uuid:48355bb0-0afd-4f73-9a18-f1e8b6fb415b">48355bb0-0afd-4f73-9a18-f1e8b6fb415b</dd></code>
<code> </dl></code>
<code></code>
<code> <dl class="target"></code>
<code> <dt><a href="http://csarven.ca/dokieli-rww#abstract" rel="oa:hasTarget">In reply to</a> (<a about="http://csarven.ca/dokieli-rww#abstract" href="http://csarven.ca/dokieli-rww" rel="oa:hasSource" typeof="oa:SpecificResource">part of</a>)</dt></code>
<code> <dd></code>
<code> <blockquote about="http://csarven.ca/dokieli-rww#abstract" cite="http://csarven.ca/dokieli-rww#abstract"></code>
<code> <div rel="oa:hasSelector" resource="i:#fragment-selector" typeof="oa:FragmentSelector"></code>
<code> <dl class="conformsto"></code>
<code> <dt>Fragment selector conforms to</dt></code>
<code> <dd><a property="rdf:value" content="abstract" xml:lang="" lang="" rel="dcterms:conformsTo" href="https://tools.ietf.org/html/rfc3987">RFC3987</a></dd></code>
<code> </dl></code>
<code></code>
<code> <dl class="refinedby" rel="oa:refinedBy" resource="i:#text-quote-selector" typeof="oa:TextQuoteSelector"></code>
<code> <dt>Refined by</dt></code>
<code> <dd><span property="oa:prefix" xml:lang="en" lang="en">rchitecture and implementation, </span><mark property="oa:exact" xml:lang="en" lang="en">demonstrating advanced document authoring and interaction without a single point of control</mark><span property="oa:suffix" xml:lang="en" lang="en">. Such an environment provides t</span></dd></code>
<code> </dl></code>
<code> </div></code>
<code> </blockquote></code>
<code> </dd></code>
<code> </dl></code>
<code></code>
<code> <dl class="renderedvia"></code>
<code> <dt>Rendered via</dt></code>
<code> <dd><a about="http://csarven.ca/dokieli-rww#abstract" href="https://dokie.li/" rel="oa:renderedVia">dokieli</a></dd></code>
<code> </dl></code>
<code></code>
<code> <section id="note-b6738766-3ce5-4054-96a9-ced7f05b439f" rel="oa:hasBody" resource="i:#note-b6738766-3ce5-4054-96a9-ced7f05b439f"></code>
<code> <h2 property="schema:name">Note</h2></code>
<code></code>
<code> <dl class="rights"></code>
<code> <dt>Rights</dt></code>
<code> <dd><a href="https://creativecommons.org/licenses/by/4.0/" rel="dcterms:rights" title="Creative Commons Attribution">CC BY 4.0</a></dd></code>
<code> </dl></code>
<code></code>
<code> <div datatype="rdf:HTML" property="rdf:value schema:description" resource="i:#note-b6738766-3ce5-4054-96a9-ced7f05b439f" typeof="oa:TextualBody">What are you trying to tell me? That I can dodge bullets?</div></code>
<code> </section></code>
<code> </article></code>
<code> </main></code>
<code> </body></code>
<code></html></code></pre>
<figcaption property="schema:name">Example annotation HTML</figcaption>
</figure>
<pre id="html-canonical"><code><dl class="canonical"></code>
<code> <dt>Canonical</dt></code>
<code> <dd rel="oa:canonical" resource="urn:uuid:48355bb0-0afd-4f73-9a18-f1e8b6fb415b">48355bb0-0afd-4f73-9a18-f1e8b6fb415b</dd></code>
<code></dl></code></pre>
<p><code>oa:canonical</code> refers to a canonical IRI that can be used to deduplicate the annotation. If an user chooses to store their annotation at their personal Webspace as well as when an annotation service (if offered), dokieli treats the resource at personal space as the canonical, and the resource at the annotation service as the copy where it refers to the personal space (<code>oa:via</code>).</p>
<p>If an annotation resource is introduced to the article's DOM as part of an <code>aside</code>, they have a structure similar to an <code>article</code>, and may be displayed in different ways, eg. in marginalia:</p>
<pre id="html-aside-do"><code><aside class="note do"></code>
<code> <blockquote cite="https://linkedresearch.org/annotation/csarven.ca/dokieli-rww/b6738766-3ce5-4054-96a9-ced7f05b439f"></code>
<code> <article about="i:" id="461819979" prefix="i: https://linkedresearch.org/annotation/csarven.ca/dokieli-rww/b6738766-3ce5-4054-96a9-ced7f05b439f" typeof="oa:Annotation"></code>
<code> <!-- Reconstruction of the original annotation (from RDF) --></code>
<code> </article></code>
<code> </blockquote></code>
<code></aside></code></pre>
<p>An inline reference to that annotation as aside would have a structure like:</p>
<pre id="html-ref-do"><code><span class="ref do" rel="schema:hasPart" resource="#r-461819979" typeof="dctypes:Text"><mark id="r-461819979" property="schema:description">demonstrating advanced document authoring and interaction without a single point of control</mark><sup class="ref-annotation"><a rel="cito:hasReplyFrom" href="#461819979" resource="https://linkedresearch.org/annotation/csarven.ca/dokieli-rww/b6738766-3ce5-4054-96a9-ced7f05b439f">💬</a></sup></span></code></pre>
<p>Note that the human-visible anchor hyperlinks (<samp>#461819979</samp>) to the annotation <code>aside id="461819979"</code>.</p>
</div>
</section>
<section id="html-notification" inlist="" rel="schema:hasPart" resource="#html-notification">
<h4 property="schema:name">Notification</h4>
<div property="schema:description">
<p>Notifications are discovered from <cite><a href="https://www.w3.org/TR/ldn/">LDN</a></cite> Inboxes. An article (or a fragment within) may have an inbox relation (<code>ldp:inbox</code>) which helps dokieli to discover it, and then fetch the notifications.</p>
<p>Notifications are intended to be brief, giving sufficient information for consumers to decide if they want use to them. If the notifications are generated by dokieli, eg. via an annotation activity, they typically include some provenance level data like generation date, actor that triggered it, license, where the annotation can be found, what it annotated, and the motivation for it. Notifications will not include the annotation body, but consumers can fetch their URLs (as mentioned in the <a href="#html-annotation">annotation section</a>).</p>
<p>See also <var>createNoteDataHTML</var> (dokieli.js)</p>
<p>Here is a notification resource at <a href="https://linkedresearch.org/inbox/csarven.ca/dokieli-rww/b6738766-3ce5-4054-96a9-ced7f05b439f">https://linkedresearch.org/inbox/csarven.ca/dokieli-rww/b6738766-3ce5-4054-96a9-ced7f05b439f</a> with all information human-visible and machine-readable (HTML+RDFa):</p>
<figure id="html-notification-view">
<object data="https://linkedresearch.org/inbox/csarven.ca/dokieli-rww/b6738766-3ce5-4054-96a9-ced7f05b439f" height="420" type="text/html" width="100%"></object>
<figcaption>A notification referring to an annotation</figcaption>
</figure>
<p>Its source:</p>
<figure class="listing" id="html-notification-source" rel="schema:hasPart" resource="#html-notification-source">
<pre about="#html-notification-source" lang="" property="schema:description" typeof="fabio:Script" xml:lang=""><code><!DOCTYPE html></code>
<code><html lang="en" xml:lang="en" xmlns="http://www.w3.org/1999/xhtml"></code>
<code> <head></code>
<code> <meta charset="utf-8" /></code>
<code> <title>Notification: Announced</title></code>
<code> </head></code>
<code> <body prefix="xsd: http://www.w3.org/2001/XMLSchema# rdf: http://www.w3.org/1999/02/22-rdf-syntax-ns# as: https://www.w3.org/ns/activitystreams# oa: http://www.w3.org/ns/oa# schema: http://schema.org/"></code>
<code> <main></code>
<code> <article></code>
<code> <h1>Notification: Announced</h1></code>
<code> <section></code>
<code> <dl about=""></code>
<code> <dt>Types</dt></code>
<code> <dd><a about="" href="https://www.w3.org/ns/activitystreams#Announce" typeof="as:Announce">Announce</a></dd></code>
<code></code>
<code> <dt>Object</dt></code>
<code> <dd><a href="https://linkedresearch.org/annotation/csarven.ca/dokieli-rww/b6738766-3ce5-4054-96a9-ced7f05b439f" property="as:object">https://linkedresearch.org/annotation/csarven.ca/dokieli-rww/b6738766-3ce5-4054-96a9-ced7f05b439f</a></dd></code>
<code></code>
<code> <dt>Target</dt></code>
<code> <dd><a href="http://csarven.ca/dokieli-rww#abstract" property="as:target">http://csarven.ca/dokieli-rww#abstract</a></dd></code>
<code></code>
<code> <dt>Updated</dt></code>
<code> <dd><time datetime="2017-04-15T21:31:45.711Z" datatype="xsd:dateTime" property="as:updated" content="2017-04-15T21:31:45.711Z">2017-04-15 21:31:45</time></dd></code>
<code></code>
<code> <dt>Actor</dt></code>
<code> <dd><a href="http://csarven.ca/#i" property="as:actor">http://csarven.ca/#i</a></dd></code>
<code></code>
<code> <dt>License</dt></code>
<code> <dd><a href="https://creativecommons.org/publicdomain/zero/1.0/" property="schema:license">https://creativecommons.org/publicdomain/zero/1.0/</a></dd></code>
<code> </dl></code>
<code></code>
<code> <dl about="https://linkedresearch.org/annotation/csarven.ca/dokieli-rww/b6738766-3ce5-4054-96a9-ced7f05b439f"></code>
<code> <dt>Object type</dt></code>
<code> <dd><a about="https://linkedresearch.org/annotation/csarven.ca/dokieli-rww/b6738766-3ce5-4054-96a9-ced7f05b439f" typeof="oa:Annotation" href="http://www.w3.org/ns/oa#Annotation">Annotation</a></dd></code>
<code></code>
<code> <dt>Motivation</dt></code>
<code> <dd><a href="http://www.w3.org/ns/oa#replying" property="oa:motivation">replying</a></dd></code>
<code> </dl></code>
<code> </section></code>
<code> </article></code>
<code> </main></code>
<code> </body></code>
<code></html></code></pre>
<figcaption property="schema:name">Example notification HTML</figcaption>
</figure>
</div>
</section>
</div>
</section>
</div>
</section>
<section id="user-interface" inlist="" rel="schema:hasPart" resource="#user-interface">
<h2 property="schema:name">User interface</h2>
<div datatype="rdf:HTML" property="schema:description">
<section id="document-modes" inlist="" rel="schema:hasPart" resource="#document-modes">
<h3 property="schema:name">Document modes</h3>
<div datatype="rdf:HTML" property="schema:description">
<p>There UI adapts to the <em>document mode</em> the user is in: <cite>author</cite>, <cite>review</cite>, <cite>social</cite>. By default the <cite>social</cite> mode is engaged. The <i class="fa fa-bars"></i> <a href="#dokieli-menu">dokieli menu</a> allows the user to engage the author mode through the <i class="fa fa-i-cursor"></i> <a href="#editor-enable">Edit</a> operation, and the review mode with <i class="fa fa-balance-scale"></i> <a href="#review-enable">Review</a>. See also <var>setDocumentMode</var> (dokieli.js).</p>
</div>
</section>
<section id="dokieli-menu" inlist="" rel="schema:hasPart" resource="#dokieli-menu">
<h3 property="schema:name">dokieli menu</h3>
<div datatype="rdf:HTML" property="schema:description">
<p about="" rel="schema:potentialAction">The <a href="#document-menu" typeof="schema:ActivateAction"><i class="fas fa-bars"></i>dokieli menu</a> enables users to access various <a href="#features">features</a>.</p>
</div>
</section>
<section id="features" inlist="" rel="schema:hasPart" resource="#features">
<h3 property="schema:name">Features</h3>
<div datatype="rdf:HTML" property="schema:description">
<dl>
<dt id="signin-user"><i class="fa fa-user-secret"></i>Sign in</dt>
<dd>Allows the user to identify themselves using their WebID where they can also authenticate themselves. dokieli retrieves information related to user's identity to adapt the user interface as well as with operations related to user's actions.</dd>
<dt id="resource-share"><i class="fa fa-bullhorn"></i>Share</dt>
<dd>The user can share the current article or a part of it with individuals or groups from their contacts as well as to any specific agent. The list of contacts is generated through a discovery mechanism where dokieli follows <samp>foaf:knows</samp> relations as well as traversing equivalent profiles (<code>owl:sameAs</code>) and determines their inboxes. dokieli sends a notification to user selected targets with information such as who sent the notification, when it was created, its license and motivation.</dd>
<dt id="resource-reply"><i class="fa fa-reply"></i>Reply</dt>
<dd>An article can be replied with a note and have its own <a href="#resource-language">language</a> and <a href="#resource-license">license</a>. The user can use the <a href="#resource-browser">resource browser</a> to choose the location of the reply in a <a href="#personal-storage">personal storage</a> or an annotation service.</dd>
<dt id="resource-activities">Activities</dt>
<dd>A <a href="#signin-user">signed-in user</a> can overlay annotations and activities that they or their contacts have created, which target the current document or a part within it.</dd>
<dt id="resource-annotations">Annotations</dt>
<dd>Articles can be annotated with various motivations. Annotations themselves can also be annotated. Some kinds of annotations are kept with the article, while others are independent resources stored externally to the article. The user may assign a specific <a href="#resource-language">language</a> and a <a href="#resource-license">license</a> for some types of annotations.
<dl>
<dt>Bookmarking</dt>
<dd>The document or selected text can be bookmarked where the user can include a note, assign <a href="#annotation-tagging">tags</a>.</dd>
<dt>Commenting</dt>
<dd>Node or text level targeting for an annotation including a <a href="#annotation-describing">description</a> and <a href="#annotation-tagging">tags</a>.</dd>
<dt>Describing</dt>
<dd>A note to indicate a footnote. Used as part of purpose for <a href="#annotation-bookmarking">bookmarking</a> and <a href="#resource-commenting">commenting</a>.</dd>
<dt>Highlighting</dt>
<dd>Node or text level targeting that gives the user a URI that they can use for deep-linking and referencing.</dd>
<dt>Replying</dt>
<dd>A note to indicate a reply to selected text or node.</dd>
<dt>Tagging</dt>
<dd>The user can associate tags (natural language text) to selected text which is used as part of purpose for annotations such as <a href="#annotation-bookmarking">bookmarking</a>, <a href="#annotation-replying">replying</a>, and <a href="#resource-commenting">commenting</a>.</dd>
<dt><i class="fa fa-thumbs-up"></i>Approve</dt>
<dd>General agreement with the selected text. Optional note can indicate why the selection is a strong point or a convincing argument.</dd>
<dt><i class="fa fa-thumbs-down"></i>Disapprove</dt>
<dd>General disagreement with the selected text. Optional note can indicate why the selection is a weak point, an error, or inaccurate.</dd>
<dt><i class="fa fa-crosshairs"></i>Specificity</dt>
<dd>Request to increase specificity on selected text. Optional note can indicate that a citation or more specificity is needed.</dd>
</dl>
</dd>
<dt id="resource-new"><i class="fa fa-lightbulb-o"></i>New</dt>
<dd>This feature allows a new document to be created at specified location. The new document is constructed based on If the user is signed in with their WebID and their personal storage location is identifier, the default location for the new resource will have the storage URL (<code>pim:storage</code>) as its base. If the user does not have a WebID and a storage, and if the article refers to an annotation service (<code>oa:annotationService</code>), it will use that URL instead. The URL can be input directly, and otherwise a name will be autogenerated for the resource. This feature uses the <cite><a href="#resource-browser">resource browser</a></cite> to navigate HTTP URLs. See also <var>generateAttributeId</var> (dokieli.js). On create, the resulting hyperlink will be shown and a new tab in the browser will be prompted.</dd>
<dt id="resource-open"><i class="fa fa-coffee"></i>Open</dt>
<dd>Documents can be opened from a local filesystem or by entering an HTTP URL. Both options read the resource's content, and if dokieli's CSS and JavaScript are not present, they are included before updating the DOM and initiating dokieli. This feature uses the <cite><a href="#resource-browser">resource browser</a></cite> to navigate HTTP URLs. See also <var>openDocument</var> (dokieli.js). There are special handling of data formats such as:
<dl>
<dt id="gps-data">GPS data</dt>
<dd>The user can view a map (OpenStreetMap) including a track, as well as details about GPS and extension data in a table such as time period, latitude, longitude, altitude, heart rate, cadence, speed, air temperature, water temperature, depth. The table also includes a summary of publication date, publisher, actor, total distance, total time, average pace, average heart rate, elevation gain, elevation lost. The nearest city of the track is also determined and linked to on Wikidata.</dd>
<dt id="activity-collection">Activity collection</dt>
<dd>A chronological list of (social) activities.</dd>
</dl>
</dd>
<dt id="resource-save"><i class="fa fa-life-ring"></i>Save</dt>
<dd>This feature makes a <a href="#http-put">write operation</a> (<code>HTTP PUT</code>) request to the current location of the document (<var>window.location</var>). The document is normalised in that dokieli related items are removed from the DOM before making the request.</dd>
<dt id="resource-save-as"><i class="fa fa-paper-plane-o"></i>Save As</dt>
<dd>The <cite>Save As</cite> operation is similar to <cite>New</cite> for normalising some of the URLs and same as <cite>Save</cite> operation for normalising the DOM before making the request to specified location. If <cite>Derivation data</cite> is checked for inclusion, <a href="#html-document-derived-from-on">derived from and on</a> information is included in the created document. This feature uses the <cite><a href="#resource-browser">resource browser</a></cite> to navigate HTTP URLs.
<dl>
<dt id="resource-set-inbox">Set Inbox</dt>
<dd>The user can associate an inbox to an article using the <a href="#resource-browser">resource browser</a>.</dd>
<dt id="resource-set-annotation">Set Annotation</dt>
<dd>The user can associate an annotation service to an article using the <a href="#resource-browser">resource browser</a> so that others' annotations can optionally be copied to this location.</dd>
<dt id="resource-dokielize">dokielize</dt>
<dd>Normalises the document to be valid, normalised, as well as includes the dokieli scripts so that the application be used in the derived version.</dd>
<dt id="resource-accessibility-report">Accessibility Report</dt>
<dd>Provides additional accessibility information about the current document so that the user can find ways to improve the content's accessibility.</dd>
<dt id="storge-details">Storage details</dt>
<dd>The user can examine information about the storage such as its location, name, description, owners, URI persistence policy, and digital rights policies as well as be informed about any conflicts with their preferred policies, and notification subscription options and subscribing to live changes.</dd>
</dl>
</dd>
<dt id="resource-version">Version</dt>
<dd>Generates a derived copy of the current document as a mutable resource including provenance.</dd>
<dt id="resource-immutable">Immutable</dt>
<dd>Generates a derived copy of the current document as an immutable or frozen Memento resource including provenance. Creates or updates a Memento TimeMap including a reference to the immutable resource.</dd>
<dt id="resource-memento">Memento</dt>
<dd>The user can access the memento (version history) of a document.</dd>
<dt id="resource-robustify-links">Robustify Links</dt>
<dd>In order to work around content-drift and link-rot, users can decorate links to include Robust Links, e.g. the URI of a snapshot from the Internet Archive, datetime stamp at the time of linking, and other context.</dd>
<dt id="resource-archive">Archive</dt>
<dd>Sends an archival request of the current article to the Internet Archive <a href="https://web.archive.org/">Wayback Machine</a>.</dd>
<dt id="generate-feed">Generate Feed</dt>
<dd>The user can generate and publish a custom web feed based on a list of documents they have selected from a storage. The user can specify the feed's title, <a href="#resource-language">language</a>, <a href="#resource-license">license</a>, and format such as RSS or Atom.</dd>
<dt id="resource-export"><i class="fa fa-external-link"></i>Export</dt>
<dd>The user can export the article as HTML and save to their local filesystem.</dd>
<dt id="resource-print"><i class="fa fa-print"></i>Print</dt>
<dd>Requests to print the current document (<code>window.print()</code>).</dd>
<dt id="editor-enable"><i class="fa fa-i-cursor"></i>Edit</dt>
<dd><cite>Editor</cite> is one of the document modes a user can be in. The available features reflect the edit operation. Edits reside in the DOM until a <cite>Save</cite> or <cite>Save As</cite> is triggered. There are content formatting and structuring features to indicate heading, italics, bold, ordered an unordered listing, inline code, preformatted text, hyperlinking, inline quotes, adding images, tables, as well as:
<dl>
<dt id="resource-interactive-embeddable-objects">Interactive and embeddable objects</dt>
<dd>User can include a chart based on statistical data such as sparklines.</dd>
<dt id="resource-semantic-annotation">Semantic annotation</dt>
<dd>The user can mark content to be both further machine-readable (RDFa) in addition to being human-readable.</dd>
<dt id="resource-footnotes-citations">Footnotes and citations</dt>
<dd>The user can create footnotes and citations for their selected text where they are contextual, robust, and the cited entity can be notified about the citation (for back-referencing). References can be ISBNs or URLs of any kind. For contextual citations for instance, the citing entity (an argument) cites the cited entity (observation results) as source of factual evidence for statements it contains. The user can also search for bibliographic information about technical specifications for the purpose citing.</dd>
<dt id="authoring-widgets">Authoring widgets</dt>
<dd>The user can add contributors to the article and send a notification to them about the article. The user can specify the document's language, license, inbox, in reply to, document type (such as article, specification, slideshow), document status, test suite.</dd>
</dl>
</dd>
<dt id="resource-autosaving">Autosaving</dt>
<dd>While the user is in <a href="#editor-enable">editing</a> their article, the document is autosaved to local storage. The user can optionally enable autosaving the resource.</dd>
<dt id="resource-source"><i class="fa fa-code"></i>Source</dt>
<dd>The user can edit the current state of the article. <em>Updating</em>, only updates the DOM, where write operations on the article resource itself are handled by features such as <a href="#resource-save">Save</a>.</dd>
<dt id="embed-data-meta"><i class="fa fa-table"></i>Embed Data</dt>
<dd>The user can embed and update supplemental data to be stored with the article using RDF syntaxes such as Turtle, JSON-LD, and TriG.</dd>
<dt id="message-log">Messages</dt>
<dd>The user can read the all of the messages that were raised to their attention by dokieli for example as the result of some action.</dd>
<dt id="dokieli-views"><i class="fa fa-magic"></i>Views</dt>
<dd>The dokieli menu will list primary and alternate stylesheets that are <a href="#html-css">detected in HTML</a>. <cite>Native</cite> is always available and it will essentially disable all other stylesheets, thereby user-agent's default stylesheets are gets applied. When a view is selected, eg. <cite>Basic</cite> (which happens to be the one that is used on this article as primary), it becomes the primary stylesheet, and the rest of the stylesheets become alternate and disabled.</dd>
<dt id="resource-graph">Graph visualisation</dt>
<dd>The user can view a graph visualisation of the document's underlying machine-readable semantics (RDFa). The view lists the resources that are in the view, number of statements, number of unique nodes, creator, license, and legend. The visualisation can be exported to an SVG.</dd>
<dt id="list-of-stuff">List of Stuff</dt>
<dd>Options to generate and include various content such as:
<dl>
<dt>Contents</dt>
<dd>For table of contents.</dd>
<dt>Figures</dt>
<dd>List of figures in the document and links to them.</dd>
<dt>Tables</dt>
<dd>List of tables in the document and links to them.</dd>
<dt>Abbreviations</dt>
<dd>List of abbreviations in the document and their definitions.</dd>
<dt>Quotations</dt>
<dd>List of quotations in the document and links to them.</dd>
<dt>Concepts</dt>
<dd>List of concept schemes and concepts in the document and links to them. The user can include additional concepts that are defined in resources that are externally references from the current document, as well as a graph visualisation of the concepts.</dd>
<dt>Requirements</dt>
<dd>Table of conformance requirements and test coverage (of a technical specification) including the requirement subject, level and statement, and test cases per requirement, and links to them. The use can optionally see the difference in changes between the current document and the previous version of the document, as well as the information from the changelog.</dd>
<dt>Advisements</dt>
<dd>Table of advisements (in a technical specification) including their levels and statements and links to them.</dd>
<dt>References</dt>
<dd>List of tables in the document and links to them.</dd>
</dl>
</dd>
</dl>
<dt id="document-metadata">Document metadata</dt>
<dd>Based on document's underlying structured data, displays information about its contributors such as editors and authors, number of citations, requirements, advisements, concepts, statements, as well as an estimated reading time, number of characters, words, and bytes.</dd>
</div>
</section>
<section id="components" inlist="" rel="schema:hasPart" resource="#components">
<h3 property="schema:name">Components</h3>
<div datatype="rdf:HTML" property="schema:description">
<dl>
<dt id="resource-license">License</dt>
<dd>The user can specify the <em>rights and license</em> for their articles and annotations from a list of <cite><a href="https://creativecommons.org/">Creative Commons</a></cite> licenses, e.g., <span resource="#annotation-rights" typeof="schema:ChooseAction">CC BY 4.0</span>. Notifications by default use the <cite><a href="https://creativecommons.org/publicdomain/zero/1.0/">CC0 1.0 Universal</a></cite> license.</dd>
<dt id="resource-language">Language</dt>
<dd>The user can assign the language of an article or an annotation from a selection (182 languages). Alternatively, the user can use the semantic annotator to specify the language of a text selection or nodes.</dd>
<dt id="resource-browser">Resource browser</dt>
<dd >The <em>resource browser</em> eg. available for <cite>New</cite>, <cite>Open</cite>, <cite>Save As</cite> operations can be used to navigate through a Webspace. It does this by using the <cite><a href="https://www.w3.org/TR/ldp/">Linked Data Platform</a></cite>'s containment rules to retrieve and then display the container's index. If the user's personal storage location is known, it will be used as default location for the resource browser. Alternatively, if the article refers to an annotation service, it will be used as start location.</dd>
<dt id="base-url-selection">Base URL selection</dt>
<dd>To determine the base URL, when new documents are created or saved as, media resources from <var>head link, [src], object[data]</var> (querySelector) will have their URLs normalised to use current document's base URL as its absolute URL (this is the <q>Use references as is</q> option). If <q>Copy to your storage</q> is selected, relative URLs will not be updated as the copy operation reuses the same file paths when resource are copied to destination. The <em>copy</em> operation does an <code>HTTP GET</code> for each source, then <code>HTTP PUT</code> to target.</dd>
<dt id="resource-clipboard">Clipboard</dt>
<dd>The user can copy the contents of preformatted text and tables (in CSV format) to their clipboard.</dd>
<dt id="resource-fragments">Fragments</dt>
<dd>The user can see and click on a fragment in the document which is useful for specific referencing.</dd>
<dt id="resource-tabs">Tabs view</dt>
<dd>Navigation items provide a tab view for the user.</dd>
</dl>
</div>
</section>
</div>
</section>
<section id="accessibility-usability-inclusion" inlist="" rel="schema:hasPart" resource="#accessibility-usability-inclusion">
<h2 property="schema:name">Accessibility, Usability, and Inclusion</h2>
<div datatype="rdf:HTML" property="schema:description">
<section id="accessibility-statement" inlist="" rel="schema:hasPart" resource="#accessibility-statement">
<h3 property="schema:name">Accessibility Statement</h3>
<div datatype="rdf:HTML" property="schema:description">
<section id="accessibility-measures-to-support-accessibility" inlist="" rel="schema:hasPart" resource="#accessibility-measures-to-support-accessibility">
<h4 property="schema:name">Measures to support accessibility</h4>
<div datatype="rdf:HTML" property="schema:description">
<p>dokieli takes the following measures to ensure accessibility of dokieli:</p>
<ul class="organizational-effort accessibility-measures">
<li>Include accessibility throughout our internal policies.</li>
<li>Assign clear accessibility goals and responsibilities.</li>
<li>Employ formal accessibility quality assurance methods.</li>
</ul>
</div>
</section>
<section id="accessibility-conformance-status" inlist="" rel="schema:hasPart" resource="#accessibility-conformance-status">
<h4 property="schema:name">Conformance status</h4>
<div datatype="rdf:HTML" property="schema:description">
<p>The <a href="https://www.w3.org/WAI/standards-guidelines/wcag/">Web Content Accessibility Guidelines (WCAG)</a> defines requirements for designers and developers to improve accessibility for people with disabilities. It defines three levels of conformance: Level A, Level AA, and Level AAA. dokieli is partially conformant with WCAG 2.1 level AA. Partially conformant means that some parts of the content do not fully conform to the accessibility standard.</p>
</div>
</section>
<section id="accessibility-feedback" inlist="" rel="schema:hasPart" resource="#accessibility-feedback">
<h4 property="schema:name">Feedback</h4>
<div datatype="rdf:HTML" property="schema:description">
<p>We welcome your feedback on the accessibility of dokieli. Please let us know if you encounter accessibility barriers on <a href="https://github.com/linkeddata/dokieli/issues">dokieli issues</a>.</p>
</div>
</section>
<section id="accessibility-technical-specifications" inlist="" rel="schema:hasPart" resource="#accessibility-technical-specifications">
<h4 property="schema:name">Technical specifications</h4>
<div datatype="rdf:HTML" property="schema:description">
<p>Accessibility of dokieli relies on the following technologies to work with the particular combination of web browser and any assistive technologies or plugins installed on your computer:</p>
<ul>
<li>HTML</li>
</ul>
<p>These technologies are relied upon for conformance with the accessibility standards used.</p>
</div>
</section>
<section id="accessibility-assessment-approach" inlist="" rel="schema:hasPart" resource="#accessibility-assessment-approach">
<h4 property="schema:name">Assessment approach</h4>
<div datatype="rdf:HTML" property="schema:description">
<p>dokieli assessed the accessibility of dokieli by the following approaches:</p>
<ul>
<li>Self-evaluation</li>
</ul>
</div>
</section>
</div>
</section>
<section id="authoring-accessibility" inlist="" rel="schema:hasPart" resource="#authoring-accessibility">
<h3 property="schema:name">Authoring accessibility</h3>
<div datatype="rdf:HTML" property="schema:description">
<section id="authoring-tool-user-interface-accessibility" inlist="" rel="schema:hasPart" resource="#authoring-tool-user-interface-accessibility">
<h4 property="schema:name">Authoring tool user interface accessibility</h4>
<div datatype="rdf:HTML" property="schema:description">
<dl>
<dt>Web-based functionality is accessible</dt><dd>partially</dd>
<dt>Non web-based functionality is accessible</dt><dd>not applicable</dd>
<dt>Alternative content available to editors</dt><dd>partially</dd>
<dt>Description</dt><dd>Possible to add alternative content through dokieli's source editor feature. Improvements in the UI will be available in a future version.</dd>
<dt>Editing-view presentation can be programmatically determined</dt><dd>yes</dd>
<dt>Works with keyboard</dt><dd>partially</dd>
<dt>Description</dt><dd>There are some WAI-ARIA landmarks.</dd>
<dt>Enough time</dt><dd>yes</dd>
<dt>Flashing content optional</dt><dd>yes</dd>
<dt>Content can be navigated by structure</dt><dd>yes</dd>
<dt>Content searchable</dt><dd>no</dd>
<dt>Supports display preferences</dt><dd>yes</dd>
<dt>Previews are accessible</dt><dd>not applicable</dd>
<dt>Helps editor prevent and correct mistakes</dt><dd>yes</dd>
<dt>(Accessibility) features documented</dt><dd>partially</dd>
</dl>
</div>
</section>
<section id="support-for-producing-accessible-content" inlist="" rel="schema:hasPart" resource="#support-for-producing-accessible-content">
<h4 property="schema:name">Support for producing accessible content</h4>
<div datatype="rdf:HTML" property="schema:description">
<dl>
<dt>Generates accessible markup</dt><dd>yes</dd>
<dt>Preserves accessibility information</dt><dd>yes</dd>
<dt>Accessible content production is possible</dt><dd>yes</dd>
<dt>Editors guided</dt><dd>partially</dd>
<dt>Text alternatives can be managed</dt><dd>partially</dd>
<dt>Accessible templates available</dt><dd>yes</dd>
<dt>Accessible components/plug-ins available</dt><dd>no</dd>
<dt>Checks accessibility automatically</dt><dd>yes</dd>
<dt>Provides suggestions to content editor about accessibility problems</dt><dd>partially</dd>
<dt>Description</dt><dd>There is an accessibility report provided on 'save as' feature including a list of issues that can be corrected by the content editor.</dd>
<dt>Accessibility features prominent</dt><dd>no</dd>
<dt>Documentation promotes accessibility</dt><dd>not provided</dd>
</dl>
</div>
</section>
</div>
</section>
</div>
</section>
<section id="http-operations" inlist="" rel="schema:hasPart" resource="#http-operations">
<h2 property="schema:name">HTTP operations</h2>
<div datatype="rdf:HTML" property="schema:description">
<p>dokieli conforms to <cite><a href="https://www.w3.org/TR/ldp/" rel="cito:citesAsAuthority">Linked Data Platform</a></cite> (LDP) protocol for create, update, and delete operations.</p>
<p id="http-put">Article operations like <cite>New</cite>, <cite>Save</cite>, <cite>Save As</cite>, <cite>Reply</cite> use <code>HTTP PUT</code>, <cite>Review</cite> and other annotation operations use <code>HTTP POST</code>.</p>
<p id="http-post">Notifications are sent with <code>HTTP POST</code>. <cite>Save</cite> and <cite>Save As</cite> normalises the HTML before sending.</p>
<table id="http-request-to-send">
<caption>Request to send</caption>
<thead>
<tr>
<th></th>
<th>HTTP method(s)</th>
<th><code>Content-Type</code></th>
</tr>
</thead>
<tbody>
<tr><th>Article</th><td><code>PUT</code></td><td><code>text/html</code></td></tr>
<tr><th>Annotation</th><td><code>OPTIONS</code>, <code>POST</code></td><td><code>text/html</code>, <code>application/ld+json</code>, <code>text/turtle</code></td></tr>
<tr><th>Notification</th><td><code>OPTIONS</code>, <code>POST</code></td><td><code>text/html</code>, <code>application/ld+json</code>, <code>text/turtle</code></td></tr>
</tbody>
<tfoot>
<tr>
<td colspan="3">
<dl>
<dt id="request-to-send-article">Article</dt>
<dd>Articles typically use <code>text/html</code> with embedded RDFa. Where a server implements <code>GET</code> with <code>text/html</code>, and allows <code>PUT</code> for writing, the assumption is that it can allow <code>text/html</code>. In the future, dokieli can check for the <code>Accept-Put</code> header with <code>OPTIONS</code> to determine a suitable type. At this time, HTML+RDFa is an important default for articles.</dd>
<dt id="request-to-send-annotation">Annotation</dt>
<dd>Annotations use the <code>POST</code> method with <code>Content-Type</code> header value determined by type of location to write to: personal storage space eg. given a profile's <code>pim:storage</code>; made to an annotation service eg. an article's <code>oa:annotationService</code>; sent to profile's outbox's outbox: <code>as:outbox</code>. The <cite><a href="https://www.w3.org/TR/annotation-protocol/">Web Annotation Protocol</a></cite> requires <code>application/ld+json</code> by default. dokieli sends an <code>OPTIONS</code> request to check for the <code>Accept-Post</code> header and sends the payload in one of the serializations that the server prefers. If it is not set, it will fallback to <code>application/ld+json</code> as preferred by Wen Annotation and ActivityPub.</dd>
<dt id="request-to-send-notification">Notification</dt>
<dd>Notifications use <code>OPTIONS</code> to check the response's <code>Accept-Post</code> HTTP header. If it is set and matches one of the acceptable RDF mediatypes that dokieli can parse, it will use that mediatype to serialize the payload before <code>POST</code>ing. <span rel="schema:hasPart" resource="#dokieli-notification-post-content-type-json-ld">If it is not set, it will fallback to <code>application/ld+json</code> as required by the <cite><a href="https://www.w3.org/TR/ldn/#test-sender-header-post-content-type-json-ld" rel="cito:citesAsAuthority">Linked Data Notifications</a></cite> specification.</span></dd>
</dl>
</td>
</tr>
</tfoot>
</table>
<aside id="http-patch">
<p>Current reasons for using <code>HTTP POST</code> and <code>PUT</code> instead of <code>PATCH</code>:</p>
<ul>
<li>Servers with <cite><a href="https://tools.ietf.org/html/rfc5261" rel="cito:citesAsAuthority">XML Patch</a></cite> and mediatype <code>application/xml-patch+xml</code> (<cite><a href="https://tools.ietf.org/html/rfc7351" rel="cito:citesAsAuthority">RFC 7351</a></cite>) capability in the Linked Data ecosystem are not well supported.</li>
<li><code>HTTP PATCH</code> with <cite><a href="https://www.w3.org/TR/sparql11-update/" rel="cito:citesAsAuthority">SPARQL Update</a></cite> (using mediatype <code>application/sparql-update</code>) would not work for RDFa representations because it would require additional server-side knowledge: HTML+RDFa serializer. This also makes server implementations a dependency for dokieli which is an undesirable design pattern.</li>
<li><code>HTTP PATCH</code> can help to optimise HTTP requests provided that the server processes the SPARQL query and eventually publishes the final state of the article. dokieli's use of <code>HTTP POST</code> and <code>HTTP PUT</code> on the other hand does not expect or impose operations other than to store and serve the article. If servers would like to do versioning and how, dokieli leaves it to the servers to decide.</li>
</ul>
</aside>
<p id="http-proxy">Due to <cite><a href="https://www.w3.org/TR/mixed-content/">Mixed Content</a></cite> implementations in Web browsers, ie. <q>fetching of content over unencrypted or unauthenticated connections in the context of an encrypted and authenticated document</q>, is subject to being blocked by the Web browser. Hence, an https document (eg article at https) will not be able to use the contents of an http document (eg. an http WebID). As a workaround, dokieli uses a proxy endpoint by default in order to use the contents of an http resource. An https document fetching an https resource will not use the proxy.</p>
</div>
</section>
<section id="authentication" inlist="" rel="schema:hasPart" resource="#authentication">
<h2 property="schema:name">Authentication</h2>
<div datatype="rdf:HTML" property="schema:description">
<p>dokieli was originally intended to handle different authentication mechanisms. <a href="https://www.w3.org/2005/Incubator/webid/spec/tls/">WebID-TLS</a> is currently supported to authenticate with servers.</p>
</div>
</section>
<section id="storage" inlist="" rel="schema:hasPart" resource="#storage">
<h2 property="schema:name">Storage</h2>
<div datatype="rdf:HTML" property="schema:description">
<dl>
<dt id="personal-storage">Personal storage</dt>
<dd>WebID's with <code>pim:storage</code> can get to use their personal online data storage with dokieli's read-write operations, eg all annotations, <cite>Reply</cite>, <cite>Review</cite>, <cite>New</cite>, <cite>Save As</cite>.</dd>
<dt id="local-storage">Local storage</dt>
<dd>There is a <cite>Local Storage</cite> feature which uses user-agent's <var>window.localStorage</var>, with default 1m autosave.</dd>
</dl>
</div>
</section>
<section id="web-extension" inlist="" rel="schema:hasPart" resource="#web-extension">
<h2 property="schema:name">Web Extension</h2>
<div datatype="rdf:HTML" property="schema:description">
<p>The dokieli <cite><a href="https://developer.mozilla.org/en-US/Add-ons/WebExtensions">Web Extension</a></cite> is a minimal package of dokieli which contains the core CSS and JavaScript that works as a browser add-on. When user triggers it from their browser toolbar, it provides the same functionality as a <cite>single-page application</cite>, ie. initialised and rendered in the browser DOM.</p>
<p>Currently the extension works with Firefox and Chromium browsers. The extension can be used in the following way:</p>
<ol>
<li>Clone the dokieli repository from <a href="https://github.com/linkeddata/dokieli">https://github.com/linkeddata/dokieli</a> (or forked copy) to your local machine.</li>
<li>
<dl>
<dt>Firefox</dt>
<dd>From the "Add-ons and themes" menu, select "Debug Add-ons" (or go to <code>about:debugging#/runtime/this-firefox</code> from the addressbar) and import by selecting any file from the cloned dokieli directory (e.g., <code>manifest.json</code>). See also <a href="https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Temporary_Installation_in_Firefox">temporary installation in Firefox</a>. Note that if you restart your browser, you'll need to go through this process.</dd>
<dt>Chromium</dt>
<dd>The general process for browsers such as Chrome, Brave, Vivaldi, <a href="https://en.wikipedia.org/wiki/Chromium_(web_browser)#Browsers_based_on_Chromium">etc.</a>, are as follows. From the "Extensions" menu (or go to <code>chrome://extensions/</code>, <code>brave://extensions</code>, <code>vivaldi://extensions/</code> from addressbar), check the "developer mode" option. Import the dokieli directory from "Load unpacked".</dd>
</dl>
</li>
</ol>
</div>
</section>
<section id="development" inlist="" rel="schema:hasPart" resource="#development">
<h2 property="schema:name">Development</h2>
<div datatype="rdf:HTML" property="schema:description">
<pre><code>git clone https://github.com/linkeddata/dokieli</code>
<code>cd dokieli</code>
<code></code>
<code># Install packages</code>
<code>yarn install</code>
<code></code>
<code># Build eg. to create scripts/dokieli.js</code>
<code>yarn build</code>
<code></code>
<code># or automatically rebuild when files change</code>
<code>yarn watch</code></pre>
</div>
</section>
</div>
</article>
</main>
</body>
</html>