-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathmodel.html
More file actions
1897 lines (1734 loc) · 123 KB
/
Copy pathmodel.html
File metadata and controls
1897 lines (1734 loc) · 123 KB
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
<!DOCTYPE html>
<html lang="en"
prefix="schema: https://schema.org/ rdf: http://www.w3.org/1999/02/22-rdf-syntax-ns# rdfs: http://www.w3.org/2000/01/rdf-schema# dcterms: http://purl.org/dc/terms/ oa: http://www.w3.org/ns/oa# cito: http://purl.org/spar/cito/ prov: http://www.w3.org/ns/prov# as: https://www.w3.org/ns/activitystreams# sio: http://semanticscience.org/resource/ na: https://w3id.org/nanoarguments/ np: http://www.nanopub.org/nschema# npx: http://purl.org/nanopub/x/ rel: https://www.w3.org/ns/iana/link-relations/relation# spec: http://www.w3.org/ns/spec# doap: http://usefulinc.com/ns/doap#">
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1" />
<title>Nanoarguments: Vocabulary Survey and Model Specification</title>
<link rel="canonical" href="https://knowledgepixels.com/nanoarguments/model.html" />
<link href="https://dokie.li/media/css/basic.css" media="all" rel="stylesheet" />
<link href="https://dokie.li/media/css/dokieli.css" media="all" rel="stylesheet" />
<script src="https://dokie.li/scripts/dokieli.js"></script>
<style>
.toc > li[data-id="changelog"] { counter-increment: none !important; }
.toc > li[data-id="changelog"]::before { content: "\00a0\00a0\00a0\00a0" !important; margin-right: 0 !important; }
</style>
</head>
<body>
<main>
<article about="" typeof="schema:Article" prefix="schema: https://schema.org/">
<h1 property="schema:name">Nanoarguments: Vocabulary Survey and Model Specification</h1>
<dl id="document-authors">
<dt>Author</dt>
<dd id="Virginia-Balseiro"><a href="https://virginiabalseiro.com/#me" rel="schema:creator schema:author" typeof="schema:Person">Virginia Balseiro</a></dd>
</dl>
<dl id="document-editors">
<dt>Editors</dt>
<dd id="editor-Virginia-Balseiro"><a href="https://virginiabalseiro.com/#me" rel="schema:editor" typeof="schema:Person">Virginia Balseiro</a></dd>
<dd id="editor-Tobias-Kuhn"><a href="https://www.tkuhn.org/" rel="schema:editor" typeof="schema:Person">Tobias Kuhn</a></dd>
<dd id="editor-Ashley-Caselli"><a href="https://ashleycaselli.github.io/" rel="schema:editor" typeof="schema:Person">Ashley Caselli</a></dd>
</dl>
<dl id="document-published">
<dt>Published</dt>
<dd><time content="2026-06-22T00:00:00Z" datatype="xsd:dateTime" datetime="2026-06-22" property="schema:datePublished">2026-06-22</time></dd>
</dl>
<dl id="document-latest-published-version">
<dt>Latest published version</dt>
<dd><a href="https://knowledgepixels.com/nanoarguments/model.html" rel="rel:latest-version">https://knowledgepixels.com/nanoarguments/model.html</a></dd>
</dl>
<dl id="document-version">
<dt>Version</dt>
<dd><span property="schema:version">0.1.2</span></dd>
</dl>
<dl id="document-type">
<dt>Document Type</dt>
<dd><a href="http://usefulinc.com/ns/doap#Specification" rel="rdf:type">Specification</a></dd>
</dl>
<section id="abstract" rel="schema:hasPart" resource="#abstract" inlist>
<h2 property="schema:name">Abstract</h2>
<div property="schema:abstract" datatype="rdf:HTML">
<p>This is the first published deliverable of the Nanoarguments project: a vocabulary and model specification
for representing scholarly discourse and evidence as decentralized, signed, queryable knowledge graphs.</p>
<p>The project's goal is to let scholarly conversations (claims and responses, support and dispute, evidence
and caveats) live as structured, persistent data on a federated network, instead of as ephemeral threads
tied to specific platforms. A claim posted in one venue should be referenceable from another; a response
should be linkable to its target by IRI regardless of where either was published; the resulting graph should
be queryable across documents, tools, and communities. This requires a shared vocabulary for the relations
that make a discussion legible as discourse: who supports or disputes what, who replies to whom, what counts
as evidence, what cites what.</p>
</div>
</section>
<section id="audience" rel="schema:hasPart" resource="#audience" inlist>
<h2>Audience</h2>
<p>This document is for readers interested in adopting, extending, or reviewing the model: researchers, ontology
contributors, tool developers, and community organizers working on decentralized scholarly communication. The
model specification assumes familiarity with linked data and RDF; the vocabulary survey introduces each
candidate ontology, so prior familiarity with every one is not required.</p>
</section>
<section id="content" rel="schema:hasPart" resource="#content" inlist>
<h2>Content</h2>
<p>This document includes:</p>
<ul>
<li>A vocabulary survey reviewing the W3C and community ontologies that already cover parts of this space: Web
Annotation, CiTO, PROV-O, SIO, ECO, SEPIO, AMO, Activity Streams, ActivityPub, Linked Data Notifications.
Each entry describes the vocabulary's scope and how this model uses it.</li>
<li>A model specification defining the Nanoarguments model: how content nodes are typed and identified, what
relations connect them, how the model maps onto the nanopublication container format and projects to
ActivityPub for federation, and what query patterns the resulting graph supports.</li>
</ul>
</section>
<section id="out-of-scope" rel="schema:hasPart" resource="#out-of-scope" inlist>
<h2>Out of scope</h2>
<p>Some work that complements this specification is being addressed in other Nanoarguments project milestones:
</p>
<ul>
<li>Templates and query infrastructure. Standard query templates and templates for data input.</li>
<li>Integrations with tools and platforms. Connector implementations bridging the model to external tools and
federation protocols.</li>
<li>Pilot rollout and adoption. Validation and iteration with pilot communities.</li>
</ul>
<p>The following are out of scope for the project as a whole and may be addressed by future work:</p>
<ul>
<li>Aggregation queries such as equivalence resolution, evidence aggregation, and agent-level metrics.
Deferred to a follow-up specification effort (<a href="#level-2-aggregation-queries">Level 2: aggregation queries</a>).</li>
<li>A canonical convention for which property identifies a contribution's source application (<a href="#source-application-or-platform">Source application or platform</a>).</li>
</ul>
</section>
<section id="part-1" rel="schema:hasPart" resource="#part-1" inlist>
<h2 id="vocabulary-survey">Vocabulary Survey</h2>
<section id="survey-scope" rel="schema:hasPart" resource="#survey-scope" inlist>
<h3>Scope of this Survey</h3>
<p>This survey reviews vocabularies and ontologies that cover parts of what a model for decentralized
scholarly discourse needs to express: statements as content nodes, relations between statements (support,
dispute, citation, reply), provenance and evidence typing, federation, and notification delivery.</p>
<p>The vocabularies covered fall into four loose groups: vocabularies for typing statements (schema.org, SIO),
vocabularies for typing relations between statements (CiTO, AMO), vocabularies for recording provenance and
evidence (PROV-O, ECO, SEPIO), and vocabularies for anchoring, federating, and notifying (Web Annotation,
Activity Streams, ActivityPub, LDN).</p>
<p>Out of scope: vocabularies covering domain-specific scientific knowledge (e.g. Gene Ontology, ChEBI),
bibliographic metadata vocabularies beyond the citation-typing case (e.g.: BIBO, FaBIO), and general purpose
upper ontologies (e.g. BFO). They either operate at the wrong layer or address concerns adjacent to
discourse-graph representation.</p>
<p>Each entry below describes the vocabulary's scope, core terms, and notable limitations or design
boundaries. How the Nanoarguments model uses each vocabulary is documented separately in the model
specification (Part II).</p>
</section>
<section id="existing-vocabularies" rel="schema:hasPart" resource="#existing-vocabularies" inlist>
<h3>Existing Vocabularies and Ontologies</h3>
<section id="vocab-schema-org" rel="schema:hasPart" resource="#vocab-schema-org" inlist>
<h4>Schema.org</h4>
<p><a rel="dcterms:references" href="https://schema.org/">https://schema.org/</a></p>
<p><strong>Summary:</strong> Schema.org is a collaborative vocabulary maintained by Google, Yahoo,
Microsoft, and Yandex, primarily used for marking up structured data on web pages so search engines and
other consumers can interpret content. It defines a hierarchy of types (with <code>schema:Thing</code> at
the root) and a flat set of properties, deployed in JSON-LD, Microdata, and RDFa across a substantial
fraction of the web.</p>
<p>Schema.org's coverage is broad (events, places, products, creative works, medical concepts,
organizations, persons) and growing through a public extension process. Several of its types are directly
relevant to scholarly discourse, including <code>schema:CreativeWork</code>, <code>schema:Article</code>,
<code>schema:Statement</code>, and <code>schema:Claim</code>.</p>
<p>Core terms (relevant subset):</p>
<ul>
<li><code>schema:Statement</code>: "a statement about something, for example a fun or interesting fact."
Extends <code>schema:CreativeWork</code>.</li>
<li><code>schema:Question</code>: "A specific question - e.g. from a user seeking answers online, or
collected in a Frequently Asked Questions (FAQ) document." Extends <code>schema:Comment</code>.</li>
<li><code>schema:Claim</code>: "a specific, factually-oriented claim that could be the itemReviewed in a
ClaimReview." Targeted at fact-checking contexts.</li>
<li><code>schema:CreativeWork</code>: the broad parent class for authored works, with properties for
author, date, license, and so on.</li>
</ul>
<p>Limitations / scope notes:</p>
<p><code>schema:Statement</code> is currently in schema.org's "new" area, meaning its definition may evolve
as implementations and feedback shape it. Adopters should track changes.</p>
<p>The distinction between <code>schema:Statement</code> and <code>schema:Claim</code> is formality and
intent: a Claim is the kind of factually-oriented assertion that gets reviewed by fact-checkers, while a
Statement is broader and includes everyday observations, opinions, hypotheses, and other contributions
that don't necessarily commit to being factually evaluated.</p>
<p>Schema.org's relations vocabulary is sparse for discourse purposes: it covers authorship, dates,
licensing, and structural document properties, but not rhetorical relations between contributions. A model
that uses schema.org for typing typically needs to combine it with another vocabulary (CiTO, PROV-O) for
relations.</p>
</section>
<section id="vocab-web-annotation" rel="schema:hasPart" resource="#vocab-web-annotation" inlist>
<h4>Web Annotation Data Model (W3C Rec, 2017)</h4>
<p><a rel="dcterms:references" typeof="doap:Specification" href="https://www.w3.org/TR/annotation-model/">https://www.w3.org/TR/annotation-model/</a></p>
<p><strong>Summary:</strong> The Web Annotation Data Model is a W3C Recommendation defining a structured way
to associate a body of information with a target resource. It supports arbitrary targets (documents, parts
of documents via selectors, other annotations, arbitrary URIs), multiple bodies, and motivation typing
through <code>oa:Motivation</code> and the <code>oa:motivatedBy</code> predicate. It is the foundation of
W3C's annotation work, including the Web Annotation Protocol (delivery) and Web Annotation Vocabulary
(extended terms).</p>
<p>Core terms:</p>
<ul>
<li><code>oa:Annotation</code></li>
<li><code>oa:hasBody</code> / <code>oa:hasTarget</code></li>
<li><code>oa:Motivation</code></li>
<li><code>oa:motivatedBy</code></li>
<li><code>oa:hasSelector</code> (text-quote selector, XPath selector, etc.; see <a
href="https://www.w3.org/TR/annotation-model/#selectors">selectors</a>)</li>
<li><code>oa:purpose</code> (role of a body vs motivation which is the role of the whole annotation -
enables multi body annotations with distinct roles)</li>
</ul>
<p>Limitations/gaps:</p>
<p>Web Annotation's scope is body-to-target anchoring with typed motivation, with optional selectors for
parts of the target. This model uses <code>oa:Annotation</code> where this scope fits and uses direct
triples between content nodes for rhetorical relations where no anchoring is involved (<a href="#relations-on-statements">Relations on statements</a>, <a href="#discourse-and-annotation-layers">Discourse and annotation layers</a>).</p>
<p><code>oa:motivatedBy</code> specifically expects an <code>oa:Motivation</code> instance as its object.
Using it to carry a CiTO property is a domain stretch; placing the discourse relation on the body resource
(which is itself an addressable RDF resource) is a cleaner alternative.</p>
</section>
<section id="vocab-amo" rel="schema:hasPart" resource="#vocab-amo" inlist>
<h4>Argument Model Ontology</h4>
<p><a rel="dcterms:references" href="http://purl.org/spar/amo">http://purl.org/spar/amo</a></p>
<p><strong>Summary:</strong> AMO is a SPAR ontology that encodes <a
href="https://owl.purdue.edu/owl/general_writing/academic_writing/historical_perspectives_on_argumentation/toulmin_argument.html">Toulmin's
model of argument</a>. It defines six interrelated components (claim, evidence, warrant, backing,
qualifier, rebuttal) organized as roles within an <code>amo:Argument</code> container. The first three
(claim, evidence, warrant) are mandatory components of an argument; the others are optional. AMO is
aligned with CiTO, which this model already uses.</p>
<p>Core terms:</p>
<ul>
<li><code>amo:Argument</code> (the container)</li>
<li><code>amo:ArgumentationEntity</code> (umbrella for the component types)</li>
<li><code>amo:Claim</code>, <code>amo:Evidence</code>, <code>amo:Warrant</code>, <code>amo:Backing</code>,
<code>amo:Qualifier</code>, <code>amo:Rebuttal</code> (the components)</li>
<li>Object properties: <code>amo:hasClaim</code>, <code>amo:hasEvidence</code>,
<code>amo:hasWarrant</code> (and the others), plus inter-component relations like
<code>amo:proves</code> (evidence → claim), <code>amo:leadsTo</code> (warrant → claim),
<code>amo:backs</code> (backing → warrant), <code>amo:forces</code> (qualifier → claim),
<code>amo:isValidUnless</code> (claim → rebuttal)</li>
</ul>
<p>Limitations / gaps:</p>
<p>The component classes are definitionally tied to an argument container. Every individual typed
<code>amo:Claim</code> is by the ontology's semantics the claim of some <code>amo:Argument</code>. Typing
a content node <code>amo:Claim</code> would commit us to a Toulmin-structured argument the content node
may not be part of.</p>
<p>The natural-language scope is also narrower than what we need. <code>amo:Claim</code> is "a fact that
must be established," operationally the thing a Toulmin argument is trying to prove. Our use case is
broader: any propositional statement contributes to the discourse graph, whether or not it is the
conclusion of an argument.</p>
<ul>
<li>AMO's <code>amo:Qualifier</code> is a simple degree-of-certainty modifier ("certainly," "possibly,"
"presumably"), without support for more complex cases such as linking caveats.</li>
<li>AMO's <code>amo:Rebuttal</code> is a restriction on a claim's validity ("unless X happens"). It is
narrower than the everyday "rebuttal" usage and not directly equivalent to a <code>cito:disputes</code>
reply.</li>
<li>AMO remains a useful candidate for pilot communities that want to structure contributions according to
Toulmin's framework. See the spec's <a href="#extensions-for-richer-structure">Extensions for richer structure</a> for the extension.</li>
</ul>
</section>
<section id="vocab-sepio" rel="schema:hasPart" resource="#vocab-sepio" inlist>
<h4>SEPIO - Scientific Evidence and Provenance Information Ontology</h4>
<p><a rel="dcterms:references"
href="https://github.com/monarch-initiative/SEPIO-ontology/wiki/The-SEPIO-Core-Ontology">https://github.com/monarch-initiative/SEPIO-ontology/wiki/The-SEPIO-Core-Ontology</a>
</p>
<p><strong>Summary:</strong> SEPIO is a domain ontology developed by the Monarch Initiative for representing
scientific evidence and its provenance. It targets graded support across multiple independent evidence
items, conflicting lines of evidence on a shared proposition, and chained provenance trails. SEPIO was
developed in alignment with the Global Alliance for Genomics and Health (GA4GH) information model and is
used in clinical and biomedical evidence-curation infrastructure.</p>
<p>Core terms:</p>
<ul>
<li>Assertion</li>
<li>Proposition</li>
<li>Evidence Line</li>
<li>Evidence Item</li>
<li>Contribution</li>
</ul>
<p>Limitations/gaps:</p>
<p>SEPIO's structural topology is fixed: assertions, propositions, evidence lines, and evidence items each
play specific roles. Adopting SEPIO as the core would force every contribution into this topology, which
is heavier than most Nanoarguments' use cases need.</p>
<p>The published OWL ontology has also drifted from the GA4GH-aligned information model that SEPIO's
documentation references, so adoption would require pinning to a specific version.</p>
</section>
<section id="vocab-prov-o" rel="schema:hasPart" resource="#vocab-prov-o" inlist>
<h4>PROV-O (W3C Rec)</h4>
<p><a rel="dcterms:references" typeof="doap:Specification" href="https://www.w3.org/TR/prov-o/">https://www.w3.org/TR/prov-o/</a></p>
<p><strong>Summary:</strong> PROV-O is the W3C-recommended OWL ontology for representing provenance. It
captures who generated what, when, from what source, through what activity. The core triad is
<code>prov:Entity</code>, <code>prov:Activity</code>, and <code>prov:Agent</code>. Attribution,
derivation, generation, association, and informing relations connect them. PROV-O is widely deployed
across scientific data publishing, including the nanopublication ecosystem, where it is the canonical
vocabulary for the provenance graph.</p>
<p>Core terms:</p>
<ul>
<li><code>prov:Entity</code>, <code>prov:Activity</code>, <code>prov:Agent</code></li>
<li><code>prov:wasGeneratedBy</code>, <code>prov:used</code>, <code>prov:wasAttributedTo</code>,
<code>prov:wasDerivedFrom</code>, <code>prov:wasAssociatedWith</code>, <code>prov:wasInformedBy</code>
</li>
</ul>
<p>Limitations/gaps:</p>
<p>PROV-O is generic by design. Its relations cover provenance broadly without committing to domain-specific
notions of derivation, evaluation, or implementation. The Nanoarguments model uses PROV-O for what it
covers (attribution, derivation, generation) and mints <code>na:tests</code> and
<code>na:implements</code> for the domain-specific relations PROV-O doesn't aim to provide (<a href="#relations-on-statements">Relations on statements</a>).</p>
<p>The nanopublication network uses PROV-O conventions specific to its own structure; this specification
follows those conventions (<a href="#provenance-and-authorship">Provenance and authorship</a>) per the nanopublication guidelines.</p>
</section>
<section id="vocab-cito" rel="schema:hasPart" resource="#vocab-cito" inlist>
<h4>CiTO - Citation Typing Ontology</h4>
<p><a rel="dcterms:references"
href="https://sparontologies.github.io/cito/current/cito.html">https://sparontologies.github.io/cito/current/cito.html</a>
</p>
<p><strong>Summary:</strong> CiTO is a SPAR ontology that types citations and references between scholarly
works (and, more generally, between any two resources where one references the other). It defines a flat
set of citation-typing properties grouped into positive, negative, neutral, and factual categories. CiTO
is widely deployed across the scholarly publishing ecosystem and is one of the most commonly reused
vocabularies for typed scholarly relationships.</p>
<p>Core terms:</p>
<ul>
<li><code>cito:cites</code> / <code>cito:isCitedBy</code></li>
<li>positive: <code>cito:supports</code>, <code>cito:confirms</code>, <code>cito:extends</code></li>
<li>negative: <code>cito:disputes</code>, <code>cito:refutes</code>, <code>cito:critiques</code>,
<code>cito:disagreesWith</code></li>
<li>neutral: <code>cito:reviews</code>, <code>cito:discusses</code>, <code>cito:citesAsAuthority</code>
</li>
<li>factual: <code>cito:usesMethodIn</code>, <code>cito:usesDataFrom</code>,
<code>cito:citesAsDataSource</code></li>
<li><code>cito:Citation</code> + <code>cito:hasCitingEntity</code> /
<code>cito:hasCitationCharacterization</code> / <code>cito:hasCitedEntity</code></li>
</ul>
<p>Limitations/gaps:</p>
<p>CiTO was primarily designed to type citations between scholarly works (document/work-level citation
relationships). It can represent statement-level citation and support relations, but statement-centric
knowledge graphs are not its principal design focus. Systems such as dokieli use it at statement or
fragment granularity by treating statements as addressable RDF resources and applying CiTO relations
between them.</p>
</section>
<section id="vocab-eco" rel="schema:hasPart" resource="#vocab-eco" inlist>
<h4>ECO - Evidence & Conclusion Ontology</h4>
<p><a rel="dcterms:references" href="http://evidenceontology.org/">http://evidenceontology.org/</a></p>
<p><strong>Summary:</strong> ECO is a community-curated controlled vocabulary of evidence categories used to
describe the type of evidence supporting a scientific assertion. It provides a structured hierarchy of
evidence types crossed with assertion methods, producing leaf terms like "experimental evidence used in
manual assertion" or "computational evidence used in automatic assertion." ECO is widely deployed in
biomedical resources including the Gene Ontology and UniProt.</p>
<p>Core terms:</p>
<ul>
<li>evidence (root class)</li>
<li>assertion method (root class - manual assertion / automatic assertion)</li>
<li>evidence x assertion method cross-product leaf terms</li>
</ul>
<p>Limitations/gaps:</p>
<p>ECO types evidence; it does not type contributions more broadly. It complements rather than replaces
other vocabularies in this survey. A contribution typed <code>sio:evidence</code> may optionally carry an
ECO class as a finer-grained subtype (<a href="#optional-evidence-typing-with-eco">Optional evidence typing with ECO</a>). ECO is not required by the model.</p>
</section>
<section id="vocab-sio" rel="schema:hasPart" resource="#vocab-sio" inlist>
<h4>SIO - Semanticscience Integrated Ontology</h4>
<p><a rel="dcterms:references"
href="https://github.com/MaastrichtU-IDS/semanticscience">https://github.com/MaastrichtU-IDS/semanticscience</a>
</p>
<p><strong>Summary:</strong> SIO is a broad upper-level ontology for the description of scientific objects,
processes, and information. It provides class hierarchies for propositions, evidence, hypotheses,
arguments, processes, and roles, along with general-purpose relations. SIO sits above more specific domain
ontologies and provides shared abstractions across biology, chemistry, and other sciences.</p>
<p>Core terms:</p>
<ul>
<li><code>sio:argument</code></li>
<li><code>sio:evidence</code></li>
<li><code>sio:justification</code></li>
</ul>
<p>Limitations/gaps:</p>
<p>SIO provides the class hierarchy for hypothesis, evidence, argument, and proposition. This model uses SIO
classes for typing and supplies the relations among them through CiTO and project-minted predicates (<a href="#relations-on-statements">Relations on statements</a>,
<a href="#sio-subtypes">SIO subtypes</a>).</p>
</section>
<section id="vocab-activitypub" rel="schema:hasPart" resource="#vocab-activitypub" inlist>
<h4>ActivityPub</h4>
<p><a rel="dcterms:references" typeof="doap:Specification" href="https://www.w3.org/TR/activitypub/">https://www.w3.org/TR/activitypub/</a></p>
<p><strong>Summary:</strong> ActivityPub is a W3C-recommended decentralized social networking protocol built
on Activity Streams 2.0. It defines a client-to-server API (clients post to a user's outbox) and a
server-to-server federation protocol (servers deliver activities to recipients' inboxes). Each actor has
an inbox and an outbox.</p>
<p>Core terms:</p>
<ul>
<li>Actor (inbox / outbox)</li>
<li>delivery (outbox -> inbox federation)</li>
</ul>
<p>Limitations/gaps:</p>
<p>ActivityPub is a federation transport, not a content vocabulary. This model's content lives in
nanopublications, and the connector layer projects nanopublications into ActivityPub activities when
federation is needed. ActivityPub and nanopublications have different commitments (federated messaging vs
signed immutable graphs), and the connector cannot be fully faithful to both (<a href="#alignment-with-activitypub">Alignment with ActivityPub</a>).</p>
</section>
<section id="vocab-activitystreams" rel="schema:hasPart" resource="#vocab-activitystreams" inlist>
<h4>Activity Streams 2.0 (alignment target)</h4>
<p><a rel="dcterms:references" typeof="doap:Specification"
href="https://www.w3.org/TR/activitystreams-vocabulary/">https://www.w3.org/TR/activitystreams-vocabulary/</a>
</p>
<p><strong>Summary:</strong> Activity Streams 2.0 is a W3C-recommended vocabulary for describing social
activities and objects on the web. It defines a small set of activity types (Create, Update, Like, Follow,
and others) and object types (Note, Article, etc.), along with relations like <code>as:inReplyTo</code>
(threading), <code>as:object</code>, and <code>as:actor</code>. It is the data model underlying
ActivityPub federation.</p>
<p>Core terms:</p>
<ul>
<li><code>as:Activity</code> (and activity subtypes: Create, Update, etc.)</li>
<li><code>as:Note</code></li>
<li><code>as:Object</code>, <code>as:actor</code>, <code>as:object</code></li>
<li><code>as:inReplyTo</code></li>
</ul>
<p>Limitations / gaps:</p>
<p>Activity Streams covers conversational structure and social activities. This model uses
<code>as:inReplyTo</code> for threading and uses CiTO predicates for rhetorical typing, treating the two
as independent axes (<a href="#discourse-graph-relations">Discourse-graph relations</a>).</p>
</section>
<section id="vocab-ldn" rel="schema:hasPart" resource="#vocab-ldn" inlist>
<h4>Linked Data Notifications</h4>
<p><a href="https://www.w3.org/TR/ldn/">https://www.w3.org/TR/ldn/</a></p>
<p><strong>Summary:</strong> Linked Data Notifications (LDN) is a W3C-recommended protocol for delivering
structured notifications to a target resource's inbox. The target declares an <code>ldp:inbox</code> IRI;
senders POST notification payloads to it. LDN is transport-only and the payload contents are arbitrary
linked data (typically Activity Streams activities or Web Annotations).</p>
<p>Core terms:</p>
<ul>
<li><code>ldp:inbox</code></li>
</ul>
<p>Limitations/gaps:</p>
<p>LDN delivers notifications but does not define their semantics. The model treats LDN as one available
transport channel for annotation delivery; the model itself doesn't depend on LDN being used.</p>
</section>
</section>
<section id="background" rel="schema:hasPart" resource="#background" inlist>
<h3>Background</h3>
<p><strong>Reply-To in dokieli:</strong></p>
<p>A reply in dokieli is a Web Annotation with the motivation <code>oa:replying</code>. Its
<code>oa:hasTarget</code> points at the resource being replied to, which can be either an article or another
annotation (so nested replies work by chaining targets).</p>
<p>For federation, the same reply also carries <code>as:inReplyTo</code> from Activity Streams, pointing at
the same target. The reply itself is stored in the author's personal storage as a first-class resource with
its own URL and provenance.</p>
<p>To make the target aware of the reply, dokieli uses Linked Data Notifications: it discovers the target's
<code>ldp:inbox</code> and POSTs a small notification (who, when, motivation, license, link to fetch the
body). dokieli also checks for <code>oa:annotationService</code> in case the article advertises one (where
annotations can be sent to).</p>
<p>The notification is a pointer, not the reply body. The target's UI then pulls the full reply when it needs
to display the thread. The annotation may also reach other destinations depending on what the user does with
it. If the user sends it to their ActivityPub outbox, the AP server wraps it in an activity and delivers a
notification to the inboxes of the user's followers. If the user sends it to an
<code>oa:annotationService</code> (which points to an Annotation Container managed via the Web Annotation
Protocol), the annotation is deposited into that container. These are separate user actions from publishing
the annotation to storage and notifying the target via LDN; storage, LDN, AP outbox, and annotation
container are independent transports, and a user may do any subset of them.</p>
<p>So one reply travels through three transports: storage (where it lives), LDN (how the target finds out
about it), and ActivityPub (how federated platforms find out about it). The Web Annotation shape is just how
the reply describes itself.</p>
<p><strong>Web Annotation caveat for our use case:</strong></p>
<p>The Web Annotation model associates a body with a target via a typed motivation. The body's standing as a
contribution comes from what the body is, not from being wrapped in an annotation. Peer reviews, replies,
and bookmarks are all annotations in WA terms, and all unambiguously first-class.</p>
<p>The design question for this model is where the discourse relations between contributions should live: on
the annotation that wraps a body-target association, or directly on the content node. Putting
<code>cito:disputes</code> on the annotation alongside <code>oa:hasBody</code> and <code>oa:hasTarget</code>
conflates two separable jobs. The annotation reifies the body-target association; the discourse relation
expresses a rhetorical stance. Putting the discourse relations directly on the content node, and letting the
annotation do only the anchoring it was designed for, produces a layering that is queryable from either
angle (<a href="#discourse-and-annotation-layers">Discourse and annotation layers</a>).</p>
<p>The resulting layers are orthogonal. The discourse layer lives on content nodes; the annotation layer wraps
a body-target association when one is needed. Both layers are first-class.</p>
<p><strong>Resolution:</strong></p>
<p>We considered two approaches: wrapping every contribution as an <code>oa:Annotation</code> to match
dokieli's emission convention, or restricting <code>oa:Annotation</code> to cases where its machinery is
actually doing work, anchoring via a selector, carrying a motivation, or otherwise saying something about
the body-target association that a direct triple between content nodes cannot carry.</p>
<p>The orthogonal-layers model (<a href="#discourse-and-annotation-layers">Discourse and annotation layers</a>) resolves this. Discourse relations live on content nodes as direct
triples, giving them a single canonical placement that supports one-hop queries for "what does this
contribution dispute or support." <code>oa:Annotation</code> is used when an authoring tool produces an
annotation as part of its flow (as dokieli does when a user selects a passage), or when a contribution needs
to express anchoring, motivation, or other association-level information.</p>
<p>The two are not alternatives. A contribution may have only discourse triples on its content node. It may
have only an annotation, associating a body with a target. It may have both: the body of an annotation is
itself a content node and carries its own discourse relations independently of being wrapped.
Implementations consuming the network should be prepared to receive any of these shapes.</p>
<p><strong>Criteria for using <code>oa:Annotation</code>:</strong></p>
<p>Use <code>oa:Annotation</code> when the link itself needs to be a first-class object: when there is
something to say about the connection between body and target that a direct triple between content nodes
cannot carry. Cases:</p>
<ul>
<li>The link carries a selector or <code>oa:SpecificResource</code> narrowing the target to a specific
section, fragment, region, or other part inside a target (a passage of a paper, a sentence inside a
claim).</li>
<li>The link carries a motivation (<code>oa:replying</code>, <code>oa:assessing</code>,
<code>oa:reviewing</code>, etc.) that the contribution wants to record alongside the body-target
association.</li>
<li>The contribution is authored by a tool that produces annotations as part of its flow (dokieli is the
canonical case. Every contribution it authors naturally has an annotation wrapper because that is its
native shape).</li>
<li>The annotation is authored separately from the body and target (for example, a curator associating two
pre-existing nanopubs).</li>
</ul>
</section>
</section>
<section id="part-2" rel="schema:hasPart" resource="#part-2" inlist>
<h2 id="model-specification">Model Specification</h2>
<section id="scope-and-purpose" rel="schema:hasPart" resource="#scope-and-purpose" inlist>
<h3>Scope and purpose</h3>
<p>This section specifies the model for discourse and evidence graphs.</p>
<p>The model is composed from existing vocabularies (Web Annotation, CiTO, PROV, SIO, with optional ECO and
SEPIO extensions) and a small project-owned namespace (<code>na:</code>), aligned with the nanopublication
container format and projected to ActivityPub for federation.</p>
<p>The model's goal is to express scholarly discourse (claims, replies, support, dispute, caveat, citation)
and the evidence that grounds it, in a form that is decentralized, signed, persistent, and queryable across
documents.</p>
</section>
<section id="namespaces" rel="schema:hasPart" resource="#namespaces" inlist>
<h3>Namespaces</h3>
<table>
<thead>
<tr>
<th>Prefix</th>
<th>Namespace</th>
</tr>
</thead>
<tbody>
<tr>
<td><code>na:</code></td>
<td><code>https://w3id.org/nanoarguments/</code></td>
</tr>
<tr>
<td><code>oa:</code></td>
<td><code>http://www.w3.org/ns/oa#</code></td>
</tr>
<tr>
<td><code>cito:</code></td>
<td><code>http://purl.org/spar/cito/</code></td>
</tr>
<tr>
<td><code>prov:</code></td>
<td><code>http://www.w3.org/ns/prov#</code></td>
</tr>
<tr>
<td><code>as:</code></td>
<td><code>https://www.w3.org/ns/activitystreams#</code></td>
</tr>
<tr>
<td><code>sio:</code></td>
<td><code>http://semanticscience.org/resource/</code></td>
</tr>
<tr>
<td><code>schema:</code></td>
<td><code>https://schema.org/</code></td>
</tr>
<tr>
<td><code>np:</code></td>
<td><code>http://www.nanopub.org/nschema#</code></td>
</tr>
<tr>
<td><code>npx:</code></td>
<td><code>http://purl.org/nanopub/x/</code></td>
</tr>
<tr>
<td><code>dct:</code></td>
<td><code>http://purl.org/dc/terms/</code></td>
</tr>
<tr>
<td><code>rdf:</code></td>
<td><code>http://www.w3.org/1999/02/22-rdf-syntax-ns#</code></td>
</tr>
<tr>
<td><code>xsd:</code></td>
<td><code>http://www.w3.org/2001/XMLSchema#</code></td>
</tr>
<tr>
<td><code>orcid:</code></td>
<td><code>https://orcid.org/</code></td>
</tr>
</tbody>
</table>
</section>
<section id="entity-classes" rel="schema:hasPart" resource="#entity-classes" inlist>
<h3>Entity classes (content nodes)</h3>
<p>A content node is a first-class RDF resource carrying the substantive content of a contribution. Each
content node has its own identifier, a type (see this section and <a href="#statement-subtypes">Statement subtypes</a>), a value (typically as
<code>rdf:value</code>), and may carry discourse relations (<a href="#relations-on-statements">Relations on statements</a>) and citations as direct triples. Content
nodes are not annotations, and do not depend on a host resource for their standing. Their identity persists
across the nanopublications and queries that reference them.</p>
<p>The same content node is referenced in several ways depending on context. As a bare node in a nanopub:</p>
<pre><code>sub:statement a schema:Statement ;
rdf:value "Pigeons can pass a modified mirror-mark test." .</code></pre>
<p>As the subject of discourse relations (<a href="#relations-on-statements">Relations on statements</a>), the claim now takes a position toward another existing claim
expressed as a direct triple:</p>
<pre><code>sub:statement a schema:Statement ;
rdf:value "Pigeons can pass a modified mirror-mark test." ;
cito:disputes <https://w3id.org/np/RAxample/claim> .</code></pre>
<p><code><https://w3id.org/np/RAxample/claim></code> is the IRI of a previously published nanopub's
content node, e.g. "Self-recognition is restricted to great apes". Disputing it does not require knowing
more about it than its IRI.</p>
<p>As the body of an annotation that anchors it to a passage, the claim is now also positioned at a specific
sentence inside an external document (in this example, a paper) via Web Annotation's selectors:</p>
<pre><code>sub:statement a schema:Statement ;
rdf:value "Pigeons can pass a modified mirror-mark test." .
sub:annot a oa:Annotation ;
oa:hasBody sub:statement ;
oa:hasTarget [ a oa:SpecificResource ;
oa:hasSource <https://example.org/chimpanzee-self-recognition> ;
oa:hasSelector [ a oa:TextQuoteSelector ;
oa:exact "no nonhuman species other than the great apes" ;
oa:prefix "We conclude that " ;
oa:suffix " demonstrates self-recognition." ] ] .</code></pre>
<p>The previous examples either reference a content node as a whole, or, in the annotation case, narrow the
target via <code>oa:SpecificResource</code> with a selector. The same selector pattern is also available as
the object of a direct discourse relation, without an enclosing <code>oa:Annotation</code>. This lets a
contribution dispute, qualify, or otherwise relate to a specific fragment of a target rather than the target
in full:</p>
<pre><code>sub:statement a schema:Statement ;
rdf:value "Recent field studies show generalization to wild populations." ;
cito:disputes [ a oa:SpecificResource ;
oa:hasSource <https://w3id.org/np/RAxample-prior-claim/claim> ;
oa:hasSelector [ a oa:TextQuoteSelector ;
oa:exact "the training does not generalize to wild populations" ] ] .</code></pre>
<p>Here the prior claim is something like "Pigeons can pass a modified mirror-mark test, but the training does
not generalize to wild populations." The disputer is taking issue only with the generalization caveat, not
the main proposition. The selector narrows the target without an <code>oa:Annotation</code> wrapper around
the disputer's own claim.</p>
<p>In every case the content node is the same RDF resource (<code>sub:statement</code>); what changes is which
other resources reference it and at what granularity. Being the body of an annotation does not constrain a
content node's discourse content: the same <code>sub:statement</code> could simultaneously carry
<code>cito:supports</code>, <code>cito:qualifies</code>, citations, or other discourse triples while being
wrapped in an annotation that anchors it to a passage.</p>
<p>This specification adopts <code>schema:Statement</code> as the base type for content nodes.
<code>schema:Statement</code> is defined by schema.org as "a statement about something." This model uses it
broadly to cover any propositional or near-propositional contribution to the discourse graph: claims,
hypotheses, observations, findings, expressions of stance, and so on. A statement carries its content in
<code>rdf:value</code>, may carry citations to external works via CiTO citation properties (<a href="#context-relations">Context relations</a>), and may
target other content nodes via discourse-graph relations (<a href="#discourse-graph-relations">Discourse-graph relations</a>).</p>
<p>A second content node type is <code>schema:Question</code>, used when a contribution asks rather than
asserts: a request for clarification, evidence, or opinion. <code>schema:Question</code> is defined by
schema.org as "a specific question, e.g. from a user seeking answers online, or collected in a Frequently
Asked Questions (FAQ) document." Like <code>schema:Statement</code>, it extends
<code>schema:CreativeWork</code> and carries its content in <code>rdf:value</code>. A question may target
another content node via <code>as:inReplyTo</code> (when the question is asked in response to a prior
contribution) or via CiTO predicates when the question is rhetorically loaded (e.g.
<code>cito:disputes</code> for a question that implicitly challenges its target). Unlike statements, which
may take any CiTO stance, a question relates to its target through a narrow, non-affirmative subset:
challenging it (<code>cito:disputes</code>, <code>cito:critiques</code>, <code>cito:qualifies</code>,
<code>cito:corrects</code>) or neutrally discussing it (<code>cito:discusses</code>), never affirming
it. A question does not <code>cito:supports</code> or <code>cito:agreesWith</code> a target; that would be an
assertion, not a question. Answers to a question are
separate content nodes that target the question; the relationship between question and answer is expressed
by the same discourse-graph relations the model uses for any other pair of contributions.</p>
<p>Schema.org's documentation recommends <code>schema:text</code> for the content of a
<code>schema:Statement</code>. This specification uses <code>rdf:value</code> instead, to align with the
nanopublication ecosystem's existing conventions (which already use <code>rdf:value</code>,
<code>rdfs:label</code>, <code>dct:title</code>, and <code>skos:prefLabel</code> across various contexts)
and to preserve the option of typed literal values such as <code>^^rdf:HTML</code>. Consumers expecting
<code>schema:text</code> may need to fall back to <code>rdf:value</code> when reading nanopublications
produced under this specification.</p>
</section>
<section id="relations-on-statements" rel="schema:hasPart" resource="#relations-on-statements" inlist>
<h3>Relations on statements</h3>
<p>Two kinds of relations sit on statements: those that connect statements to other statements (forming the
discourse graph), and those that connect a statement to a non-statement resource, anchoring the discourse
graph to external context (papers, datasets, methods, protocols).</p>
<section id="discourse-graph-relations" rel="schema:hasPart" resource="#discourse-graph-relations" inlist>
<h4>Discourse-graph relations (Statement to Statement)</h4>
<p>These relations have a statement as subject and a statement as object. They form the graph among
contributions and are what discourse-graph traversal queries (<a href="#level-1-graph-traversal-queries">Level 1: graph-traversal queries</a>) operate on.</p>
<section id="discourse-reused-from-cito" rel="schema:hasPart" resource="#discourse-reused-from-cito" inlist>
<h5>Reused from CiTO</h5>
<p>The model reuses CiTO properties without modification. The recommended subset for this version:</p>
<ul>
<li><code>cito:supports</code>: the subject contribution argues in favor of the target.</li>
<li><code>cito:disputes</code>: the subject contribution argues against the target.</li>
<li><code>cito:extends</code>: the subject contribution builds on the target.</li>
<li><code>cito:agreesWith</code>: the subject contribution endorses the target.</li>
<li><code>cito:qualifies</code>: the subject contribution places conditions or restrictions on the
target (a caveat or qualification).</li>
</ul>
<p>CiTO's full property set is available where the listed subset does not fit. Implementations should prefer
the subset to maximize interoperability and UI legibility.</p>
</section>
<section id="reused-from-activity-streams" rel="schema:hasPart" resource="#reused-from-activity-streams" inlist>
<h5>Reused from Activity Streams</h5>
<ul>
<li><code>as:inReplyTo</code>: the subject is a reply to the target, expressing conversational threading.
Used on content nodes when the contribution is a direct response to another contribution. CiTO
predicates capture rhetorical stance (<code>cito:supports</code>, <code>cito:disputes</code>, etc.) and
are independent of <code>as:inReplyTo</code>: a contribution may carry one, the other, both, or neither.
<p>A plain <code>as:inReplyTo</code> with no CiTO predicate is valid and useful for generic
conversational replies. Where a contribution carries a rhetorical stance toward its target, however, a
CiTO predicate is recommended in addition to or in place of <code>as:inReplyTo</code>, because typed
discourse is the central value the model provides. A contribution that combines threading and
rhetorical type, for example, a dispute published as a direct response to the disputed claim, should
carry both predicates.</p>
</li>
</ul>
</section>
<section id="discourse-minted-in-na" rel="schema:hasPart" resource="#discourse-minted-in-na" inlist>
<h5>Minted in na:</h5>
<ul>
<li><code>na:tests</code>: the subject contribution (a study, experiment, analysis, or similar
investigative contribution) tests the target contribution (typically a <code>sio:hypothesis</code>,
<a href="#sio-subtypes">SIO subtypes</a>). (Proposed; pending pilot confirmation.)</li>
</ul>
</section>
</section>
<section id="context-relations" rel="schema:hasPart" resource="#context-relations" inlist>
<h4>Context relations (Statement to non-Statement)</h4>
<p>These relations have a statement as subject and a non-statement resource as object, typically an external
paper, dataset, method, protocol, or other resource that exists outside the discourse graph.</p>
<section id="context-reused-from-cito" rel="schema:hasPart" resource="#context-reused-from-cito" inlist>
<h5>Reused from CiTO (citation subset):</h5>
<ul>
<li><code>cito:citesAsEvidence</code>: the subject cites the target as evidence.</li>
<li><code>cito:citesAsAuthority</code>: the subject cites the target as authoritative.</li>
<li><code>cito:usesDataFrom</code>: the subject reuses the target's data.</li>
</ul>
</section>
<section id="reused-from-prov" rel="schema:hasPart" resource="#reused-from-prov" inlist>
<h5>Reused from PROV:</h5>
<ul>
<li><code>prov:wasDerivedFrom</code>: the subject was generated from the target. Covers derivation and
grounding ("this finding follows from this study," "this conclusion is derived from this evidence"). If
both subject and object happen to be statements, the relation effectively also lives in the discourse
graph; the default case is statement-to-external-resource.</li>
</ul>
</section>
<section id="context-minted-in-na" rel="schema:hasPart" resource="#context-minted-in-na" inlist>
<h5>Minted in na:</h5>
<ul>
<li><code>na:implements</code>: the subject is a concrete realization of the target specification. A
protocol implements a method; an experimental procedure implements a study design; a piece of code
implements an algorithm. Distinct from <code>prov:wasDerivedFrom</code> (which is about derivation, not
realization) and from <code>sio:realizes</code> (which relates a process to a realizable entity rather
than two informational entities). (Proposed; pending pilot confirmation.)</li>
</ul>
</section>
</section>
<section id="relations-from-other-layers" rel="schema:hasPart" resource="#relations-from-other-layers" inlist>
<h4>Relations from other layers</h4>
<p>The annotation layer (<a href="#the-annotation-layer">The annotation layer</a>) introduces annotation properties (<code>oa:hasBody</code>,
<code>oa:hasTarget</code>, <code>oa:hasSelector</code>) that sit on <code>oa:Annotation</code> resources
rather than on content nodes. These describe anchoring (where a body is positioned in relation to a
target) and are distinct from discourse relations in subject type and purpose.</p>
<p>The body of an annotation is itself a content node and may carry the full discourse vocabulary. A body
can simultaneously be the body of an <code>oa:Annotation</code> (positioning it at a target) and the
subject of <code>cito:supports</code>, <code>cito:disputes</code>, <code>cito:qualifies</code>, scientific
relations, or citation triples. The annotation framing does not flatten or restrict the body's discourse
content; the body's RDF resource is independently a full participant in the discourse layer.</p>
</section>
</section>
<section id="discourse-and-annotation-layers" rel="schema:hasPart" resource="#discourse-and-annotation-layers" inlist>
<h3>Discourse and annotation layers</h3>
<p>The model has two orthogonal layers, each carrying a different kind of statement about a contribution.</p>
<section id="the-discourse-layer" rel="schema:hasPart" resource="#the-discourse-layer" inlist>
<h4>The discourse layer</h4>
<p>The discourse layer lives on content nodes as direct triples. Discourse relations
(<code>cito:supports</code>, <code>cito:disputes</code>, <code>cito:qualifies</code>,
<code>as:inReplyTo</code>, and other CiTO relations from the subset in section 4) sit on the content node
and connect it to its target. This layer carries statements about how a contribution relates to others in
the discussion: who supports or disputes what, who replies to whom, who qualifies whose claims.</p>
<p>The discourse layer is always present on a content node that has any discourse standing regardless of the
authoring context. It is the canonical representation of the discussion structure and what aggregation
queries (<a href="#query-patterns">Query patterns</a>) operate on.</p>
</section>
<section id="the-annotation-layer" rel="schema:hasPart" resource="#the-annotation-layer" inlist>
<h4>The annotation layer</h4>
<p>The annotation layer uses <code>oa:Annotation</code> to anchor a body (typically a content node) with a
target. The annotation is a separate, addressable resource with its own properties: a body, a target,
optionally a selector narrowing the target to a part of it, and optionally a motivation. The target may be
a document, a content node, or a part of either, expressed where appropriate as an
<code>oa:SpecificResource</code> carrying an <code>oa:hasSelector</code>. This layer carries statements
about positioning and association: which body is attached where, with what motivation, by whom.</p>
<p>The canonical case is an annotation tool that operates on documents: every tool-authored contribution
naturally carries an annotation layer with a document or part of a document as the target (dokieli is one
such tool). Annotation targets are not restricted to documents. Any addressable resource can be a target,
including other content nodes, allowing one annotation to position a contribution within a target produced
elsewhere in the network.</p>
</section>
<section id="orthogonality" rel="schema:hasPart" resource="#orthogonality" inlist>
<h4>Orthogonality</h4>
<p>The two layers are independent:</p>
<ul>
<li>A contribution may participate in the discourse layer only. Example: a claim disputing another claim,
published directly to the network, with no annotation associating it with a target.</li>
<li>A contribution may be the body of an annotation only. Example: a comment that associates itself with a
passage of a document, without taking any rhetorical position toward another content node.</li>
<li>A contribution may participate in both. Example: a rebuttal that disputes a counter-argument
(discourse layer) and is also associated with a specific passage of that counter-argument via an
annotation (annotation layer).</li>
</ul>
<p>When both layers are present they describe the contribution from different angles and do not duplicate
information. The annotation's body and the content node share an IRI as they are the same RDF resource.
The triples about that resource appear once with discourse relations stated directly on it, and the
annotation references it as <code>oa:hasBody</code>. Anchoring stays on the annotation while the
rhetorical relations stay on the content node.</p>
<figure>
<svg xmlns="http://www.w3.org/2000/svg" version="1.1" viewBox="0 0 820 380" role="img" aria-labelledby="ortho-title"
style="max-width:100%;height:auto;font-family:'Segoe UI',system-ui,sans-serif">
<title id="ortho-title">Orthogonal layers. The annotation sub:annot (an oa:Annotation) carries the anchoring relations oa:hasTarget to the target, oa:hasBody to the content node sub:statement, and oa:motivatedBy to a motivation (oa:assessing). The same sub:statement (a schema:Statement) carries the rhetorical relations cito:disputes and as:inReplyTo directly to the target. Anchoring lives on the annotation, rhetorical relations on the content node, and the body and content node are the same RDF resource.</title>
<defs>
<marker id="ah-teal" viewBox="0 0 10 10" refX="8.5" refY="5" markerWidth="7" markerHeight="7" orient="auto-start-reverse"><path d="M0,0 L10,5 L0,10 z" fill="#0b7285" /></marker>
<marker id="ah-violet" viewBox="0 0 10 10" refX="8.5" refY="5" markerWidth="7" markerHeight="7" orient="auto-start-reverse"><path d="M0,0 L10,5 L0,10 z" fill="#7048e8" /></marker>
</defs>
<path d="M250,64 Q450,28 648,138" fill="none" stroke="#0b7285" stroke-width="2" marker-end="url(#ah-teal)" />
<path d="M236,116 Q268,168 322,215" fill="none" stroke="#0b7285" stroke-width="2" marker-end="url(#ah-teal)" />
<path d="M145,116 L145,233" fill="none" stroke="#0b7285" stroke-width="2" marker-end="url(#ah-teal)" />
<path d="M530,242 Q602,188 650,158" fill="none" stroke="#7048e8" stroke-width="2" marker-end="url(#ah-violet)" />
<path d="M530,270 Q612,250 648,180" fill="none" stroke="#7048e8" stroke-width="2" marker-end="url(#ah-violet)" />
<g fill="#ECECFF" stroke="#9370DB" stroke-width="1.5">
<path d="M40,40 h210 v76 h-210 z" />
<path d="M40,235 h210 v64 h-210 z" />
<path d="M300,215 h230 v76 h-230 z" />
<path d="M650,130 h120 v64 h-120 z" />
</g>
<g>
<path d="M404,34 h92 v20 h-92 z" fill="#e7f5f8" />
<path d="M214,158 h84 v20 h-84 z" fill="#e7f5f8" />
<path d="M92,170 h106 v20 h-106 z" fill="#e7f5f8" />
<path d="M556,180 h92 v20 h-92 z" fill="#f3effe" />
<path d="M556,228 h88 v20 h-88 z" fill="#f3effe" />
</g>
<g font-size="13" text-anchor="middle" fill="#212529">
<text x="450" y="48">oa:hasTarget</text>
<text x="256" y="172">oa:hasBody</text>
<text x="145" y="184">oa:motivatedBy</text>
<text x="602" y="194">cito:disputes</text>
<text x="600" y="242">as:inReplyTo</text>
</g>
<g font-size="15" text-anchor="middle">
<text x="145" y="72" font-weight="600" fill="#1d1d2c">sub:annot</text><text x="145" y="96" fill="#495057">(oa:Annotation)</text>
<text x="145" y="263" font-weight="600" fill="#1d1d2c">oa:assessing</text><text x="145" y="285" fill="#495057">(oa:Motivation)</text>
<text x="415" y="247" font-weight="600" fill="#1d1d2c">sub:statement</text><text x="415" y="271" fill="#495057">(schema:Statement)</text>
<text x="710" y="167" fill="#1d1d2c">target</text>
</g>
<g font-size="12" fill="#495057">
<line x1="40" y1="345" x2="70" y2="345" stroke="#0b7285" stroke-width="2" marker-end="url(#ah-teal)" /><text x="78" y="349">annotation layer — anchoring</text>
<line x1="320" y1="345" x2="350" y2="345" stroke="#7048e8" stroke-width="2" marker-end="url(#ah-violet)" /><text x="358" y="349">discourse layer — rhetorical</text>
</g>
</svg>
<figcaption>The annotation layer carries anchoring (<code>oa:hasTarget</code>, <code>oa:hasBody</code>);
the discourse layer carries rhetorical relations (<code>cito:disputes</code>, <code>as:inReplyTo</code>)
on the content node.</figcaption>
</figure>
</section>
<section id="layers-and-nanopublications" rel="schema:hasPart" resource="#layers-and-nanopublications" inlist>
<h4>Layers and nanopublications</h4>
<p>The two layers may coexist in a single nanopublication when they represent one authoring act. A dokieli
user who selects a passage and writes a rebuttal in one operation produces a single nanopub whose
assertion graph contains both the rebuttal content node with its discourse triples and the annotation
anchoring the body to the passage.</p>
<p>The two layers occupy different nanopublications when they represent separate acts, for example, a
content node published in one nanopub by one author, later anchored to a passage by an annotation in a
separate nanopub by a different author or at a different time.</p>
</section>
<section id="interoperability-between-the-two-shapes" rel="schema:hasPart" resource="#interoperability-between-the-two-shapes" inlist>
<h4>Interoperability between the two shapes</h4>
<p>The two representations are alternate views of the same underlying fact, and are bidirectionally
derivable at query time.</p>
</section>
</section>
<section id="provenance-and-authorship" rel="schema:hasPart" resource="#provenance-and-authorship" inlist>
<h3>Provenance and authorship</h3>
<p>This model follows the <a href="https://nanopub.net/guidelines/working_draft/">nanopublication
guidelines</a> for authorship and provenance.</p>
<p>Authorship of the nanopublication is recorded in two places: the assertion's creator in the provenance
graph, the nanopublication's creator in the pubinfo graph. The two are conceptually distinct and may
identify different agents.</p>
<section id="assertion-authorship" rel="schema:hasPart" resource="#assertion-authorship" inlist>
<h4>Assertion authorship (provenance graph)</h4>
<p>The provenance graph records who is responsible for the content of the assertion and where the assertion
came from:</p>
<pre><code>sub:assertion prov:wasAttributedTo <agent-IRI> ;
prov:wasDerivedFrom <source-IRI> .</code></pre>
<p><code><agent-IRI></code> is an ORCID for a human author or a stable IRI for a non-human agent.
<code><source-IRI></code> (where applicable) identifies the source the assertion was derived from (a
paper, dataset, experiment, upstream nanopub). Optionally, <code>prov:generatedAtTime</code> records when
the assertion was made.</p>
<p>The provenance graph MUST contain at least one triple referencing the assertion.
<code>prov:wasAttributedTo</code> is the recommended way to do this when an agent is responsible for the
assertion's content.</p>
<p>When the assertion graph contains an <code>oa:Annotation</code> resource, the annotation's authorship is
by default the same as the assertion's: a single <code>prov:wasAttributedTo</code> on the assertion
attributes the assertion's content, including any annotation resources within it, to one agent. If the
annotation's authorship differs from the assertion's, the annotation resource carries its own attribution,
using <code>oa:creator</code> (or <code>dct:creator</code>) directly on the annotation. The common case
where this matters is third-party annotation: a curator publishes a nanopub whose assertion contains a
pre-existing claim by Author A and an annotation by the curator associating that claim with a target.</p>
</section>
<section id="nanopub-authorship" rel="schema:hasPart" resource="#nanopub-authorship" inlist>
<h4>Nanopub authorship (pubinfo graph)</h4>
<p>The pubinfo graph records who is responsible for the act of publishing the nanopub. The canonical
convention is as follows:</p>
<pre><code>this: dct:creator <agent-IRI> ;
dct:created "..."^^xsd:dateTime .</code></pre>
<p>The pubinfo SHOULD contain attribution and a timestamp. The pubinfo graph also carries the cryptographic
signature (<code>sub:sig</code> with <code>npx:signedBy</code>, <code>npx:hasPublicKey</code>,
<code>npx:hasSignature</code>), the license (<code>dct:license</code>), and any indexing properties such
as <code>npx:hasNanopubType</code>.</p>
</section>
<section id="assertion-creator-and-nanopub-creator" rel="schema:hasPart" resource="#assertion-creator-and-nanopub-creator" inlist>
<h4>Assertion creator and nanopub creator</h4>
<p>The assertion creator (provenance graph) and the nanopub creator (pubinfo graph) may identify different
agents. There are two common patterns:</p>
<ul>
<li>Same agent in both graphs: a human publishes their own assertion through an application, or an
autonomous bot does both. The same IRI appears in each graph but under different predicates
(<code>prov:wasAttributedTo</code> in provenance, <code>dct:creator</code> in pubinfo). This is not a
redundancy, as each graph attributes a different act to the same agent.</li>
</ul>
<pre><code>sub:provenance {
sub:assertion prov:wasAttributedTo orcid:0000-0003-1062-5576 .
}
sub:pubinfo {
this: dct:creator orcid:0000-0003-1062-5576 ;
dct:created "2026-06-08T08:08:08Z"^^xsd:dateTime .
}</code></pre>
<ul>
<li>Different agents in each graph: one agent authored the assertion content; a different agent (a
curator, a colleague, an organization, an automated publishing tool) is responsible for the publication
act. This pattern lets a publisher republish someone else's assertion without claiming the content as
their own, or attribute content to its source while taking responsibility for putting it on the network.
</li>
</ul>
<pre><code>sub:provenance {
sub:assertion prov:wasAttributedTo orcid:0000-0003-3934-0072 .
}
sub:pubinfo {
this: dct:creator orcid:0000-0003-0183-6910 ;
dct:created "..."^^xsd:dateTime .
}</code></pre>
</section>
<section id="tool-mediated-publishing" rel="schema:hasPart" resource="#tool-mediated-publishing" inlist>
<h4>Tool-mediated publishing</h4>
<p>When a tool publishes a nanopub on behalf of a human author, the assertion creator and the nanopub
creator may identify different agents (<a href="#assertion-creator-and-nanopub-creator">Assertion creator and nanopub creator</a>). Some patterns include:</p>
<ul>
<li>Naming the tool as <code>dct:creator</code> of the nanopub directly (the tool is the publisher)</li>
<li>Keeping the human as <code>dct:creator</code> of the nanopub and naming the tool via a separate
property (e.g. <code>npx:wasCreatedAt</code>)</li>
<li>Recording the originating session, template, or input as <code>prov:wasDerivedFrom</code></li>
</ul>
<p>This specification does not commit to a single pattern, and follows whatever the publishing tool emits.
Queries that need to identify the tool that produced a given nanopub can look for any of these properties.
A canonical emission convention may be added in a later version once the implementation milestone has
chosen one.</p>
</section>
<section id="agents" rel="schema:hasPart" resource="#agents" inlist>
<h4>Agents</h4>
<p>Agents are identified by IRIs. A human is identified by an ORCID; a bot, tool, or automated agent is
identified by a stable IRI managed by the project or organization that operates it (e.g. <a
href="https://w3id.org/kpxl/gen/terms/RoCrateBot">https://w3id.org/kpxl/gen/terms/RoCrateBot</a> ). The
model does not require type declaration on agents. An ORCID and a bot IRI are both just creators, treated
symmetrically.</p>
<p>Pubinfo may optionally carry a <code>foaf:name</code> on the agent's IRI for display purposes. This is
convenience metadata for UIs, not a requirement of the model.</p>
</section>
<section id="source-application-or-platform" rel="schema:hasPart" resource="#source-application-or-platform" inlist>
<h4>Source application or platform</h4>
<p>When a contribution originates from a federated platform or decentralized clientside tool (a discussion
forum, an annotation tool, an authoring environment), the originating platform may be recorded in pubinfo
so UIs can display source attribution ("via discussit.org") and federation logic can route accordingly.
Two properties are seen for this purpose:</p>
<ul>
<li><code>npx:wasCreatedAt</code>: used by Nanodash to identify the publishing tool.</li>
<li><code>oa:renderedVia</code>: Web Annotation property used by dokieli to identify the tool an
annotation was rendered through.</li>
</ul>
<p>Their exact semantic distinction is not documented in this specification. This document treats either as
a source of contribution marker for query and display purposes. The choice of which property to emit is
left to the publishing tool based on their specific context.</p>
</section>
<section id="nanopub-type-indexing" rel="schema:hasPart" resource="#nanopub-type-indexing" inlist>
<h4>Nanopub type indexing</h4>
<p>The pubinfo graph carries <code>npx:hasNanopubType</code> indicating the primary rhetorical or content
type of the nanopub (e.g. <code>cito:disputes</code>, <code>schema:Statement</code>,
<code>cito:qualifies</code>). Used for indexing and query.</p>
</section>
</section>