-
Notifications
You must be signed in to change notification settings - Fork 6
/
nschema.html
226 lines (210 loc) · 12 KB
/
nschema.html
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
<!DOCTYPE html>
<html lang="en">
<head>
<meta content="text/html; charset=utf-8" http-equiv="content-type">
<!-- trigger regeneration by this edit-->
<title>Guidelines for Nanopublication </title>
<!--
=== NOTA BENE === For the three scripts below, if your spec resides on dev.w3 you can check them out in the same tree and use relative links so that they'll work offline, -->
<!-- <script src="js/jquery/jquery-1.7.2.min.js"></script> -->
<!-- <script src='http://github.com/cowboy/jquery-replacetext/raw/master/jquery.ba-replacetext.js'></script>
-->
<script src="js/respec.js"></script>
<!-- <script src='http://www.openphacts.org/specs/2012/WD-datadesc-20121019/js/respec.js'></script> -->
<!-- <script src='js/jquery/jquery-1.7.2.min.js'></script> -->
<script class="remove">
var respecConfig = {
// specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
specStatus: "PR",
// the specification's short name, as in http://www.w3.org/TR/short-name/
shortName: "v1.95",
// if your specification has a subtitle that goes below the main
// formal title, define it here
// subtitle : "an excellent document",
// if you wish the publication date to be other than today, set this
// publishDate: "2012-04-07",
// if the specification's copyright date is a range of years, specify
// the start date here:
// copyrightStart: "2009"
// if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
// and its maturity status
// previousPublishDate: "1977-03-15",
// previousMaturity: "WD",
// if there a publicly available Editor's Draft, this is the link
edDraftURI: "http://nanopub.org/guidelines/working_draft",
// if this is a LCWD, uncomment and set the end of its review period
// lcEnd: "2009-08-05",
// if you want to have extra CSS, append them to this list
// it is recommended that the respec.css stylesheet be kept
extraCSS: ["http://dev.w3.org/2009/dap/ReSpec.js/css/respec.css",
"css/common.css"],
// editors, add as many as you like
// only "name" is required
editors: [
{name: "Erik Schultes", url: "", company: "LUMC", companyURL: "http://www.lumc.nl"},
{name: "Mark Thompson", url: "", company: "LUMC", companyURL: "http://www.lumc.nl"},
{name: "Paul Groth", url: "", company: "VU", companyURL: "http://www.vu.nl"},
{name: "Zuotian Tatum", url: "", company: "LUMC", companyURL: "http://www.lumc.nl"},
],
authors: [
{
name: "Alasdair J G Gray", url: "http://www.cs.man.ac.uk/~graya",
company: "University of Manchester", companyURL: "http://www.manchester.ac.uk/"
},
{name: "Christine Chichester", url: "", company: "NBIC", companyURL: "http://www.nbic.nl"},
{name: "Kees Burger", url: "", company: "NBIC", companyURL: "http://www.nbic.nl"},
{name: "Spyros Kotoulas", url: "", company: "VU", companyURL: "http://www.vu.nl"},
{name: "Antonis Loizou", url: "", company: "VU", companyURL: "http://www.vu.nl"},
{name: "Valery Tkachenko", url: "", company: "RSC", companyURL: "http://www.rsc.org"},
{
name: "Andra Waagmeester",
url: "",
company: "Maastricht University",
companyURL: "http://www.maastrichtuniversity.nl"
},
{name: "Sune Askjaer", url: "", company: "Lundbeck, ", companyURL: "www.lundbeck.com"},
{
name: "Steve Pettifer",
url: "",
company: "University of Manchester",
companyURL: "http://www.manchester.ac.uk"
},
{name: "Lee Harland", url: "", company: "Pfizer/CD", companyURL: "http://connecteddiscovery.com"},
{
name: "Carina Haupt",
url: "",
company: "Uni Bonn / Fraunhofer",
companyURL: "http://www3.uni-bonn.de/die-universitaet/events-und-veranstaltungen/deutschlandfest/angebote_stadtgebiet/fraunhofer-institute-im-b-it"
},
{name: "Colin Batchelor", url: "", company: "RSC", companyURL: "http://www.rsc.org"},
{name: "MiguelVazquez", url: "", company: "CNIO", companyURL: "http://www.cnio.es"},
{name: "José María Fernández", url: "", company: "CNIO", companyURL: "http://www.cnio.es"},
{
name: "Jahn Saito",
url: "",
company: "Maastricht University",
companyURL: "http://www.maastrichtuniversity.nl/"
},
{name: "Andrew Gibson", url: "", company: "LUMC", companyURL: "http://www.lumc.nl"},
{name: "Louis Wich", url: "", company: "DTU", companyURL: "http://www.dtu.dk"},
],
// authors, add as many as you like.
// This is optional, uncomment if you have authors as well as editors.
// only "name" is required. Same format as editors.
//authors: [
// { name: "Your Name", url: "http://example.org/",
// company: "Your Company", companyURL: "http://example.com/" },
//],
// name of the WG
wg: "In Charge Of This Document Working Group",
// URI of the public WG page
wgURI: "http://example.org/really-cool-wg",
// name (without the @w3c.org) of the public mailing to which comments are due
wgPublicList: "spec-writers-anonymous",
// URI of the patent status for this WG, for Rec-track documents
// !!!! IMPORTANT !!!!
// This is important for Rec-track documents, do not copy a patent URI from a random
// document unless you know what you're doing. If in doubt ask your friendly neighbourhood
// Team Contact.
wgPatentURI: "",
orguri: "www.nanopub.org/",//"http://www.openphacts.org/specs/",
orgicon: "<a href='http://www.nanopub.org/'><img height='100' src='figures/CWA_logo.jpg' alt='Concept Web Alliance/Nanopub.org'/></a>",
customorg: "Concept Web Alliance",
//customcss: "../css/ops.css",
specStatus: "WD",
shortName: "/guidelines/1.8",
publishDate: "2013-01-2.0",
previousMaturity: "WD",
previousPublishDate: "2012-04-30",
previousURI: "http://www.nanopub.org/guidelines/1.8",
copyrightStart: "2013",
overrideCopyright: "<p class='copyright'>This document is licensed under a <a class='subfoot' href='http://creativecommons.org/licenses/sa-by/3.0/' rel='license'>Creative Commons ShareAlike Attribution 3.0 License</a>.</p>",
};
</script>
</head>
<body>
<section id="abstract">This document describes the Nanopublication schema</section>
<section id="conformance">
<h3>The Nanopublication Schema</h3>
The nanopublication schema structures the three basic elements of a
nanopublication: (i) the assertion, (ii) the provenance of the assertion,
and (iii) the publication information of the nanopublication itself. It
combines these elements into a single referencable entity: the
nanopublication.<br>
<br>
Our reference nanopublication schema is defined in RDF, because RDF is our
recommended exchange format for nanopublications <span>(Fig X)</span>.
Thus, in version ... of the schema, a nanopublication is an instance of
type 'np:Nanopublication'. It is linked to a named graph for the
Assertion, Provenance, and PublicationInfo by the predicates '<em>hasAssertion</em>,
<em>hasProvenance</em>, and <em>hasPublicationInfo</em> respectively. The
named graphs contain the RDF statements that make up each of the elements.<br>
<h4>Assertion</h4>
The assertion graph of the nanopublication encapsulates one or more
subject-predicate-object combinations. Examples are 'Malaria <em>is
transmitted by</em> Mosquitos', or 'mutant HTT <em>causes</em>
Huntingtin's Disease'. The RDF schema requires that each of these elements
is represented by a URI (Universal Resource Identifier). We recommend
obtaining these URI from commonly used thesauri and ontologies. <br>
<br>
If you are new to RDF, then it is non-trivial to create correct RDF
statements for the assertion without supporting tools. Such tools are
becoming available, but at this time we recommend collaboration with
Semantic Web experts for converting assertions into valid RDF. We provide
additional support in a separate document on Nanopublication design
templates. The remainder of this document is a guideline who have
some experience in Semantic Web modelling.<br>
<h5>Choosing what to assert</h5>
The scope of the assertion generally depends on what the author wishes to
be known for and on the domain of discourse. We recommend to limit the
assertion triples to the absolute minimum and precisely define for what
statement credit is due. For instance, is it for the statement 'mutant
Huntingtin <em>causes</em> Huntington's Disease' for which we have
certain statistical evidence, or is it for the statistical method by which
we found this relation? In the former case, the evidence could be in the
provenance graph of the assertion, while in the latter case this evidence
will be in the assertion graph, because <em>this is what we wish to get
credit for</em>. <br>
<br>
We note that in the total RDF document, links may exist between elements
in the assertion graph and those in the provenance graph, regardless of
where we draw the boundaries of the named graphs. Furthermore, we
anticipate that communities will have their own standard procedures and
minimal requirements. If it is common in your domain to report evidence or
error values with your assertion, then they SHOULD be included there.
<br>
<h4>Provenance</h4>
Provenance means, ‘how this came to be’ and the provenance graph SHOULD
include metadata statements for the assertion, such as the methods or
parameter values used in creating the assertion, as well as attribution to
authors, institutions, and funding sources (recommended publication
roles…). The provenance graph SHOULD also contain a time/date stamp (using
pro) and MAY contain links to DOIs and URLs. A nanopublication MUST have a
provenance graph linked to the assertion (the subject being the
"assertion").
<em>[Tobias: The schema file says that the domain of hasProvenance is a
Nanopublication, not an Assertion. Which one is correct?]</em>
Additional metadata can be added to this minimal structure to accommodate
a finer-grained array of evidence factors and attribution.<br>
<br>
A third graph called publicationInfo, contains provenance metadata
statements referring to the creation of the nanopublication itself (the
subject MUST be the "nanopublicaiton") and SHOULD contain attribution and
a date/time stamp.
<em>[Tobias: What's the difference between the timestamp in the provenance
graph and the one in publicationInfo?]</em>
<br>
<br>
In order to maintain flexibility there is no requirement for OWL. These
recommendations will be exemplified and elaborated upon in a library of
nanopublication templates http://nanopub.org/wordpress/?page_id=8. The CWA
recommended nanopblucation schema is given below and can be linked to at
http://nanopub.org/nschema
<ul>
<li>Examples of nanopublication applications (including GUIs)</li>
</ul>
<br>
</section>
<br>
</body>
</html>