Difference between revisions of "ORG CR transition"

From Government Linked Data (GLD) Working Group Wiki
Jump to: navigation, search
Line 41: Line 41:
  (As agreed at [http://www.w3.org/2013/04/12-gld-minutes.html F2F3].)</i>
  (As agreed at [http://www.w3.org/2013/04/12-gld-minutes.html F2F3].)</i>
Editors will need to explain the full methodology for this document in this section.
</i>Our methodology for testing our Exit Criteria:</i>
* <i>The editors prepare test suites/test cases for their document, to be a combination of:
** objective tests (likely to be SPARQL queries to cover a majority of uses, but not necessarily be exhaustive)
** human-inspection for examples of use or misuse (likely to be script-based and look at a sample/subset of the vocabulary). 
* Implementors will run the tests themselves and return to us an implementation report.  // the inspections?
* The working group will identify a participant to facilitate this process for each document.</i>
<i>Editors will need to write in this section what goes in the test queries or checklists.</i>
== Evidence that dependencies with other groups met (or not) ==
== Evidence that dependencies with other groups met (or not) ==

Revision as of 15:40, 12 April 2013

Transition to CR

This page is to organize the documentation and evidence necessary to transition a document to Candidate Recommendation. The page's content will be used for the transition request and to inform the transition meeting for that document.

This is a working page for the Government Linked Data working group. It may be subject to change/revision at any time.


Document Abstract

Take from the document itself.

Status section and important changes to the document

  • What changes have been made to the document since Last Call?

Current URI

Final URI


  • Are there any implementation requirements beyond the defaults of the Process Document? For instance, is the expectation to show two complete implementations (e.g., there are two software instances, each of which conforms) or to show that each feature is implemented twice in some piece of software?
  • What are the Group's plans for showing implementation of optional features? In general, the Director expects mandatory features and optional features that affect interoperability to be handled similarly. Optional features that are truly optional (i.e., that do not affect interoperability) may require less implementability testing.
  • Is there a preliminary implementation report? The implementation report should be a detailed matrix showing which software implements each feature of the specification.
  • What are expectations about additional software that is expected to implement the specification during CR?
  • What is the minimal duration of the CR period? Estimate of how long it will take before requesting PR?
  • Does the WG have additional implementation experience that will help demonstrate interoperability (e.g., has there been an interoperability day or workshop? Is one planned?)?
  • Are there tests or test suites available that will allow the WG to demonstrate/evaluate that features have been implemented? If not, what metrics will the WG use? If there are special conditions for this specification related to evaluation of implementations, what are they? Are test suites planned at any time? If there are tests or test suites available, are there links between the tests and the features of the specification they purport to test?

We also need to report on all implementations we've found, even if they don't conform. <- Do we?

 Our Exit Criteria for our Vocabs is: 
 1. We should show that every single term in the vocab has been used in at least two data sources.  When doing this, we don't check if it's been used correctly. 
 2. We will have a set of SPARQL queries, and each query comes with a description of the expected results.  Like: this is a list of all the orgs mentioned in your data. We'll run these SPARQL queries and see if the results seem to match the description.  We want to have two publishers that pass all of these. 
 3. We in the WG will prepare a checklist or script saying which things need to be checked. Implementors will look at their data to see if it meets those criteria. For example:  none of the non-org term has the same semantics as an org term.  We'll say "look at your data and check for this".
(As agreed at F2F3.)

Editors will need to explain the full methodology for this document in this section.

Evidence that dependencies with other groups met (or not)

Estimated publication date

This should be the first Tuesday or Thursday after the transition meeting, which will be up to a week after the transition request is sent. In other words, allow two weeks after transition request.

Record of the Working Group's decision to request the Transition

Link to the working group meeting minutes or email where the resolution took place.

Evidence that the document satisfies group's requirements

Reference the relevant section in the Working Group's charter.

Evidence that the document has received wide review

Include links to public review comment page.

Evidence that issues have been formally addressed

(Include links to tracker and to public review comment page.)

For changes in the issues list since the previous transition:

  • Highlight issues where the Group has declined to make a change, with rationale.
  • Highlight issues where the Group has not satisfied a reviewer and has either not yet responded to the reviewer, or the reviewer has not yet acknowledged the Group's decision.
  • Show, without highlighting:
    • Issues where the Working Group has accepted a proposed change.
    • Issues where the Working Group has clarified the specification to the satisfaction of the reviewer.


  • Have there been any objections since this document went to Last Call?
  • For each objection, is there a record of the decision, the objection, and attempts to satisfy the reviewer?

Patent disclosures

We shouldn't have any for this, but reference the Working Group's Patent Disclosure page: http://www.w3.org/2004/01/pp-impl/47663/status