Changes between Version 9 and Version 10 of RdsWipOneProcess

Timestamp:

11/20/08 00:15:37 (16 years ago)

Author:

jbourne (IP: 69.156.14.78)

Comment:

--

RdsWipOneProcess

@@ -91 +91 @@
 @todo talk about the overall steps to publication
 
-=== Supported Submission Formats ===
+
+=== Submitter Requirements ===
+
+The RDS/WIP will not accept unsolicited submissions, that is submissions made without prior arrangement.  Because of the flexibility offered in terms of input and the responsibility of IDS-ADI (or other nominated body) for the published outcome, submitters must be vetted in some way.
+
+==== Vetting Submitters ====
+
+For the RDS/WIP 1.0, rather than a certification scheme (which is planned for RDS/WIP 2.0) we will have an informal system of vetting submitters.
+
+  ''The goal of this is to ensure that IDS-ADI as a group have collective faith that the submitter will participate in good faith and have an understanding of the level of process maturity and time constraints of assessor personnel.  In short, IDS-ADI need to be convinced that the submitter will be a constructive, rather than destructive influence on the RDS/WIP in the nascent stage.''
+
+@todo what is the process for vetting a submitter - SC email discussion and email vote?
+
+==== Access Credentials ====
+
+Once a submitter has been vetted, they will be have access credentials prepared for them on the ids-adi.org infrastructure and distributed to them via email.  The credentials will be for an individual, not for an organization.
+
+==== Access Rights ====
+
+Access credentials will provide a submitter with access to the
+[wiki:IDGenerator ID generation and allocation infrastructure] and with a formal measure of recognition as a submitter for administrative purposes of the RDS/WIP.  Access rights do not mean that submissions are automatically accepted for publishing under RDS/WIP 1.0, nor do they guarantee any particular response time by the assessors.
+
+=== Submission Requirements ===
+
+Since submissions are being published with an intended quality of allowing further storage and reproduction by anyone, certain requirements apply to it, including syntactic form, acceptable language, acceptable copyright terms, and semantic form.
+
+==== Syntactic Form ====
+
+Syntactic form is negotiable.  Supported forms are QMXF, QXF, RDF/XML, N3 or N-TRIPLE.
+
+@todo is the preferred form QMXF?
+
+Character set encoding of any XML form (QMXF, QXF, RDF/XML) must be formally stated in the XML header, unless it is UTF-8 - this is consistent with XML processing rules, but is restated here for emphasis.
+
+The character set encoding of N3 or N-TRIPLE must be UTF-8.
+
+All ISO 10646 code points expressible as 16 bit integers (Unicode) are acceptable in textual data.
+
+RDF identifier rules do apply to fragment identifiers, regardless of format: these rules are the same as those used for XML namespace prefix tokens (reference will be added here on request if needed).
+
+==== Acceptable Text ====
+
+A submission must not contain text intended to cause alarm or offense.  Submissions found to do so may be candidates for deletion even after publication (one of the few cases of allowed deletion).
+
+==== Copyright ====
+
+Each submission item must provide a copyright statement that allows free use of the content and any implied patents.  Copyright need not be transferred from the original party, however, anyone must be guaranteed free and unencumbered use of the information, with the exception of the responsibility to convey the copyright terms.
+
+@todo provide a list of acceptable copyrights - see OSF - suggest BSD 2 clause.
+
+==== Semantic Form ====
+
+A submission should:
+
+ * have a self-consistent semantic form (ie. not contradict itself);
+ * not be directly comparable to an existing entry.
+
+=== Recommended Process ===
+
+@todo QMXF -> QXF -> RDF -> IdGen -> triplestore
+
+=== Submission Format Options ===
 
 Three different submission formats are supported, each providing different levels of flexibility.  The more flexible, the greater the responsibility on the submitter for ensuring correctness.
@@ -149 +210 @@
 RDF has several different exchange representations: XML, N3 and N-TRIPLE.  All of these formats are acceptable inputs to the submission process.  OWL has an exchange representation of its own: OWLX - this is not currently supported as an acceptable input to the submission process.
 
-=== Submitter Requirements ===
-
-The RDS/WIP will not accept unsolicited submissions, that is submissions made without prior arrangement.  Because of the flexibility offered in terms of input and the responsibility of IDS-ADI (or other nominated body) for the published outcome, submitters must be vetted in some way.
-
-==== Vetting Submitters ====
-
-For the RDS/WIP 1.0, rather than a certification scheme (which is planned for RDS/WIP 2.0) we will have an informal system of vetting submitters.
-
-  ''The goal of this is to ensure that IDS-ADI as a group have collective faith that the submitter will participate in good faith and have an understanding of the level of process maturity and time constraints of assessor personnel.  In short, IDS-ADI need to be convinced that the submitter will be a constructive, rather than destructive influence on the RDS/WIP in the nascent stage.''
-
-@todo what is the process for vetting a submitter - SC email discussion and email vote?
-
-==== Access Credentials ====
-
-Once a submitter has been vetted, they will be have access credentials prepared for them on the ids-adi.org infrastructure and distributed to them via email.  The credentials will be for an individual, not for an organization.
-
-==== Access Rights ====
-
-Access credentials will provide a submitter with access to the
-[wiki:IDGenerator ID generation and allocation infrastructure] and with a formal measure of recognition as a submitter for administrative purposes of the RDS/WIP.  Access rights do not mean that submissions are automatically accepted for publishing under RDS/WIP 1.0, nor do they guarantee any particular response time by the assessors.
-
-=== Submission Requirements ===
-
-Since submissions are being published with an intended quality of allowing further storage and reproduction by anyone, certain requirements apply to it, including syntactic form, acceptable language, acceptable copyright terms, and semantic form.
-
-==== Syntactic Form ====
-
-Syntactic form is negotiable.  Supported forms are QMXF, QXF, RDF/XML, N3 or N-TRIPLE.
-
-@todo is the preferred form QMXF?
-
-Character set encoding of any XML form (QMXF, QXF, RDF/XML) must be formally stated in the XML header, unless it is UTF-8 - this is consistent with XML processing rules, but is restated here for emphasis.
-
-The character set encoding of N3 or N-TRIPLE must be UTF-8.
-
-All ISO 10646 code points expressible as 16 bit integers (Unicode) are acceptable in textual data.
-
-RDF identifier rules do apply to fragment identifiers, regardless of format: these rules are the same as those used for XML namespace prefix tokens (reference will be added here on request if needed).
-
-==== Acceptable Text ====
-
-A submission must not contain text intended to cause alarm or offense.  Submissions found to do so may be candidates for deletion even after publication (one of the few cases of allowed deletion).
-
-==== Copyright ====
-
-Each submission item must provide a copyright statement that allows free use of the content and any implied patents.  Copyright need not be transferred from the original party, however, anyone must be guaranteed free and unencumbered use of the information, with the exception of the responsibility to convey the copyright terms.
-
-@todo provide a list of acceptable copyrights - see OSF - suggest BSD 2 clause.
-
-==== Semantic Form ====
-
-A submission should:
-
- * have a self-consistent semantic form (ie. not contradict itself);
- * not be directly comparable to an existing entry.
-
-=== Recommended Process ===
-
-@todo QMXF -> QXF -> RDF -> IdGen -> triplestore
-
 == Distribution Detail ==