-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathTODO.txt
283 lines (221 loc) · 10.4 KB
/
TODO.txt
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
The original Sandbox plan was to implement these functionalities.
- Provides http upload function
- Provides metadata editor and other editing capabilities
* push and pull, much like workspace
However, there are talks to rethink this idea.
v0.2 wishlist
=============
General:
--------
- better workflow for managing exposures (mostly for deprecation)
- also single-click workflow change for all subobjects
- (?)
- private, use/time limited links to open model?
- complete implementation of custom search object to fit better into
the look-and-feel of the default views.
Curation Manifest:
------------------
At the core, it is just a file (probably RDF based) that lists the
checksums (both MD5 and SHA1) of the curated files, and the curation
"flags" assigned to this model.
This file could be extended to include the titles for the objects that
will be created by PMR2, i.e. rules to create the exposure.
A user then can have an offline copy of the curation information, and
when s/he goes online can verify the contents of their copy against the
one stored in PMR2. They can calculate the link, possibly something
like:
http://models.cellml.org/verify/sha1/[sha1 of their manifest file].
If an exposure was created using that manifest file, it will return the
file, giving a list of all checksums which should match the checksums in
the file the user has.
The goal of this file is to enable one-click exposure creation as the
settings used to generate the exposure pages can be saved to such a
file.
A modeler can choose to create an exposure based on this curation file
if it supports exposure type (for each file(s) s/he wishes to create an
exposure page for), title(s) of the resulting object(s), and other
presentation related fields.
Here is a sample, work in progress. The namespace URI defined for this
will be changed if and when we standardize and make this generic enough
for the usage of all model types.
::
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:cmeta="http://www.cellml.org/metadata/1.0#"
xmlns:pmr2="http://www.cellml.org/tools/pmr2/"
xmlns:dc="http://purl.org/dc/elements/1.1/">
<rdf:Description rdf:about="">
<dc:title>Smith, Jones, 2008</dc:title>
<dc:description>The Paper Title of a Citation of Model</dc:description>
<pmr2:method>Exposure</pmr2:method>
<pmr2:manifest>
<rdf:Seq>
<rdf:li rdf:resource="imports"/>
<rdf:li rdf:resource="smith_jones_2008_main.cellml"/>
<rdf:li rdf:resource="smith_jones_2008_simulation1.cellml"/>
<rdf:li rdf:resource="smith_jones_2008_simulation2.cellml"/>
</rdf:Seq>
</pmr2:manifest>
<pmr2:defaultpage rdf:resource="smith_jones_2008_main.cellml"/>
<pmr2:curation>
<rdf:Seq>
<rdf:li rdf:resource="urn:pmr2:curation:units_checked:matched"/>
<rdf:li rdf:resource="urn:pmr2:curation:expert_checked:false"/>
<rdf:li rdf:resource="urn:pmr2:curation:opencell:0.7"/>
<rdf:li rdf:resource="urn:pmr2:curation:pcenv:0.6"/>
<rdf:li rdf:resource="urn:pmr2:curation:pcenv:0.5"/>
<rdf:li rdf:resource="urn:pmr2:curation:cor:0.9"/>
</rdf:Seq>
</pmr2:curation>
</rdf:Description>
<rdf:Description rdf:about="imports">
<dc:title>Modules</dc:title>
<pmr2:method>Folder</pmr2:method>
<pmr2:manifest>
<rdf:Seq>
<rdf:li rdf:resource="imports/mod1.cellml"/>
<rdf:li rdf:resource="imports/mod2.cellml"/>
</rdf:Seq>
</pmr2:manifest>
</rdf:Description>
<rdf:Description rdf:about="imports/mod1.cellml">
<dc:title>Overview of Module 1</dc:title>
<pmr2:checksum rdf:parseType="Resource">
<pmr2:md5>67a533bb34bfbdf2a88bf4b02c69db5e</pmr2:md5>
<pmr2:sha1>6ad972d2839d0f8224b5156bb039d5389c24c774</pmr2:sha1>
</pmr2:checksum>
<pmr2:method>Module Overview Exposure</pmr2:method>
<pmr2:curation_remove>
<rdf:Seq>
<rdf:li rdf:resource="urn:pmr2:curation:expert_checked:false"/>
</rdf:Seq>
</pmr2:curation_remove>
<pmr2:curation_insert>
<rdf:Seq>
<rdf:li rdf:resource="urn:pmr2:curation:expert_checked:true"/>
</rdf:Seq>
</pmr2:curation_insert>
</rdf:Description>
<rdf:Description rdf:about="imports/mod2.cellml">
<dc:title>Overview of Module 2</dc:title>
<pmr2:checksum rdf:parseType="Resource">
<pmr2:md5>07628e76b5b61165ee6170df435aca9a</pmr2:md5>
<pmr2:sha1>c66b6af43f2efcc15413e602d008cf9fd701c29b</pmr2:sha1>
</pmr2:checksum>
<pmr2:method>Module Overview Exposure</pmr2:method>
<pmr2:curation_remove>
<rdf:Seq>
<rdf:li rdf:resource="urn:pmr2:curation:expert_checked:false"/>
</rdf:Seq>
</pmr2:curation_remove>
<pmr2:curation_insert>
<rdf:Seq>
<rdf:li rdf:resource="urn:pmr2:curation:expert_checked:true"/>
</rdf:Seq>
</pmr2:curation_insert>
</rdf:Description>
<rdf:Description rdf:about="smith_jones_2008_main.cellml">
<dc:title>Smith, Jones, 2008</dc:title>
<dc:description>
The Paper Title of a Citation of Model (Main Model)
</dc:description>
<pmr2:checksum rdf:parseType="Resource">
<pmr2:md5>f6a1c5ac3b58a26fff7cdcc4a44030bd</pmr2:md5>
<pmr2:sha1>250ec366f6dc0ad8620f04c474f330e19d6b4a0e</pmr2:sha1>
</pmr2:checksum>
<pmr2:method>PMR2 Style Exposure</pmr2:method>
</rdf:Description>
<rdf:Description rdf:about="smith_jones_2008_simulation1.cellml">
<dc:title>Smith, Jones, 2008</dc:title>
<dc:description>
The Paper Title of a Citation of Model (Simulation 1)
</dc:description>
<pmr2:checksum rdf:parseType="Resource">
<pmr2:md5>802c35f3327306d47198cc40217dc64d</pmr2:md5>
<pmr2:sha1>a506625616003a705ecca9bc19c5f981441e3569</pmr2:sha1>
</pmr2:checksum>
<pmr2:method>PMR1 Style Exposure</pmr2:method>
</rdf:Description>
<rdf:Description rdf:about="smith_jones_2008_simulation2.cellml">
<dc:title>Smith, Jones, 2008</dc:title>
<dc:description>
The Paper Title of a Citation of Model (Simulation 2)
</dc:description>
<pmr2:checksum rdf:parseType="Resource">
<pmr2:md5>f5a32cae906b59f3ef5f1fe5c552a68a</pmr2:md5>
<pmr2:sha1>b2f90f4f71f6885d36f6c7c99b9d54c7f8cf6bb0</pmr2:sha1>
</pmr2:checksum>
<pmr2:method>PMR1 Style Exposure</pmr2:method>
</rdf:Description>
</rdf:RDF>
A few notes:
- We are using a "temporary" namespace URI to identify the manifest:
http://www.cellml.org/tools/pmr2/
- The node with rdf:about="" is the root container for all the
subobjects defined.
- Each manifest within a node can only define paths within its own
directory. Note how imports directory has a separate definition
- Manifest must be in a Seq so order can be defined for the
navigational elements of PMR2.
- Each entry should have a title and description, or one will be
generated by PMR2.
- One can also reference another snippet of RDF within another
RDF file through this::
<dc:title rdf:resource="main.cellml#title">
Which the main.cellml will be parsed for RDF content, and the
literal with the id 'title' will be used.
- The folder type objects (Exposure, Folder) will need to define
a defaultpage, or a bare minimum index page is generated.
- Curation at the root object applies to every single files under
it, but each files can override it using pmr2:curation_remove or
pmr2:curation_insert. Or perhaps even override by redefining the
tag. [XXX: this will need much further discussion]
- Curation is defined using URN, to aid in future migration towards
using standardized curation ontologies.
- Checksums are to aid curators in determining whether the contents
of the curated files have changed since the last time the flags
were put into place.
- Checksums were put into place as a crutch for "offline"
verification of the curated model content. Providing a revision
identifier might probably do the trick, since it will contain
the real checksums of the files the user want to check against,
and this may be somewhat simpler.
- This file is only "recipe" to create the final, curated exposure
pages for use within PMR2. All curation values, checksums, and
other information exists for convenience and are not authoritative
in determining the validity of the curation flags against the
content. While the checksums and the like can be checked against
this manifest, users will still need to verify that this manifest
file was used to create an exposure that has been validated by a
curator.
Exposure Workflow
-----------------
Exposures should really only have one single workflow state for the
entire container to simplify control. Also, curation flags should apply
to each file, not the entire container.
Exposure Type
-------------
We need our expousures to look better, include related models, other
curation status flags.
Metadata Editing:
-----------------
PMR1 had an online metadata editing. This was originally slated to be
part of the Sandbox, but if we ditch the sandbox there will be no way
to safely edit metadata online. However, we can still have an offline
metadata editor, and it should be able to present and allow editing of
any arbitrary metadata. It should also save metadata back to where it
was originally found in the XML document.
This RDF metadata could also be used to edit the curation manifest file.
Listing of models:
------------------
More versatile index page that can do listing by alphabetical order and
the like.
Workspace Exposure Listing:
---------------------------
Clean up that listing so a user can see what has been exposed at a
glance, and in chronological order if possible. For performance needs
the commit id along with its dates will need to be indexed.
Searching/Catalog:
------------------
ZCatalog is legacy, not versatile and pollutes objects with unneeded
methods. See if we can integrate the newer catalogs.