Difference between revisions of "ORG CR transition"

From Government Linked Data (GLD) Working Group Wiki
Jump to: navigation, search
(Evidence that the document has received wide review)
(Implementations)
Line 43: Line 43:
 
==Implementations==
 
==Implementations==
  
* <i>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?
+
=== CR Exit criteria ===
* 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?</i>
+
  
<i>It would be useful (but not required) to report on all implementations we've found, even if they don't conform.</i>
+
The working group intends to submit this document for consideration as a W3C Proposed Recommendation after having met the following criteria:
  
  <i>Our Exit Criteria for our Vocabs is:
+
* Each feature of ORG is demonstrated to have been used in two independent data sources, in conformance with the specification.
  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.  
+
* At least one such implementation of each feature will have been cross-verified by a member of the Working Group or a delegated expert.
  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 [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.
+
=== Validating Conformance ===
 +
 
 +
To test conformance of a data source with the ORG specification the working group has defined a validation suite. This comprises a set of SPARQL queries which, for each feature of the vocabulary, will extract the relevant information represented by that feature. This is not an automated test suite, human interpretation is required to determine if the query results are as expected for the source data. See [[ORG Validation Suite]].
 +
 
 +
The Working Group ''may'' provide an on-line tool to ease use of this validation suite.
 +
 
 +
An implementation report will comprise:
 +
* Outline description of the implementation.
 +
* A list of features implemented.
 +
* A declaration that for each implemented feature the results of the validation tests are appropriate.
 +
* Optionally, a confirmation that a Working Group member, or delegated expert, has confirmed conformance.
 +
 
 +
The final manual validation step enables checking of conformance criteria which cannot be test through a validation suite. Specifically that the data source does not use terms from other vocabularies ''instead'' of ones defined in ORG that could reasonably be used.
 +
 
 +
=== Features ===
 +
 
 +
{|
 +
! Feature
 +
! Terms
 +
|-
 +
| Core
 +
| <code>org:Organization</code> <code>org:FormalOrganization</code> <code>org:identifier</code> <code>org:classification</code> <code>org:purpose</code>
 +
|-
 +
| Sites and addresses
 +
| <code>org:siteOf</code> <code>org:hasSite</code> <code>org:hasPrimarySite</code> <code>org:hasRegisteredSite</code> <code>org:siteAddress</code> <code>org:basedAt</code>
 +
|-
 +
| Structure
 +
| <code>org:hasSubOrganization</code> <code>org:subOrganizationOf</code> <code>org:OrganizationUnit</code> <code>org:unitOf</code> <code>org:hasUnit</code>
 +
|-
 +
| Membership
 +
| <code>org:Role</code> <code>org:Membership</code> <code>org:role</code> <code>org:member</code> <code>org:organization</code> <code>org:memberDuring</code> <code>org:hasMember</code> <code>org:memberOf</code> <code>org:memberOf</code> <code>org:roleProperty</code> <code>org:headOf</code>
 +
|-
 +
| Posts
 +
| <code>org:Post</code> <code>org:hasPost</code> <code>org:postIn</code> <code>org:holds</code> <code>org:heldBy</code>
 +
|-
 +
| Organization change
 +
| <code>org:ChangeEvent</code> <code>org:changedBy</code> <code>org:originalOrganization</code> <code>org:resultedFrom</code> <code>org:resultingOrganization</code>
 +
|-
 +
| Collaboration
 +
| <code>org:OrganizationalCollaboration</code>
 +
|}
 +
 
 +
A valid use of a feature is not required to use every term listed withing that feature.
 +
 
 +
=== At risk features ===
 +
 
 +
=== Known implementations ===
  
 
== Evidence that dependencies with other groups met (or not) ==
 
== Evidence that dependencies with other groups met (or not) ==

Revision as of 16:55, 1 May 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.

ORG Timetable

Title

An organization ontology

Document Abstract

This document describes a core ontology for organizational structures, aimed at supporting linked data publishing of organizational information across a number of domains. It is designed to allow domain-specific extensions to add classification of organizations and roles, as well as extensions to support neighbouring information such as organizational activities.

Status section and important changes to the document

The changes made are documented at https://dvcs.w3.org/hg/gld/raw-file/default/org/index.html#change-history and listed below for convenience.

  • Added explicit declarations that org:member and org:organization are functional properties. This is a clarification rather than an intended change of semantics.
  • Removed assertion that org:Post is a sub class of org:Organization, adding an informative note that ORG applications are still free to declare entities as being instances of both classes.
  • Added property chain axiom for prov:wasDerivedFrom.
  • Removed the range constraint on org:siteAddress to allow other encodings than VCard to be used.
  • Added a statement that org:Organization is equivalent to the foaf:Organization class. This statement was present in the ontology itself at the time of last call but not sufficiently clear in this document.
  • Removed informative comment that the org:reportsTo graph is acyclic, this is not necessarily the case.

Do we need to generate a viewable diff? If so are there tools for that?

The WG examined these changes and determined that they are not substantive (mostly clarifications), do not invalidate any implementations that might have been created in accordance with the Last Call version and so do not warrant another Last Call period. [resolution]

Current URI

http://www.w3.org/TR/2012/WD-vocab-org-20121023/

Final URI

http://www.w3.org/TR/2012/CR-vocab-org-20130523/

Is this what this section means?

Implementations

CR Exit criteria

The working group intends to submit this document for consideration as a W3C Proposed Recommendation after having met the following criteria:

  • Each feature of ORG is demonstrated to have been used in two independent data sources, in conformance with the specification.
  • At least one such implementation of each feature will have been cross-verified by a member of the Working Group or a delegated expert.

Validating Conformance

To test conformance of a data source with the ORG specification the working group has defined a validation suite. This comprises a set of SPARQL queries which, for each feature of the vocabulary, will extract the relevant information represented by that feature. This is not an automated test suite, human interpretation is required to determine if the query results are as expected for the source data. See ORG Validation Suite.

The Working Group may provide an on-line tool to ease use of this validation suite.

An implementation report will comprise:

  • Outline description of the implementation.
  • A list of features implemented.
  • A declaration that for each implemented feature the results of the validation tests are appropriate.
  • Optionally, a confirmation that a Working Group member, or delegated expert, has confirmed conformance.

The final manual validation step enables checking of conformance criteria which cannot be test through a validation suite. Specifically that the data source does not use terms from other vocabularies instead of ones defined in ORG that could reasonably be used.

Features

Feature Terms
Core org:Organization org:FormalOrganization org:identifier org:classification org:purpose
Sites and addresses org:siteOf org:hasSite org:hasPrimarySite org:hasRegisteredSite org:siteAddress org:basedAt
Structure org:hasSubOrganization org:subOrganizationOf org:OrganizationUnit org:unitOf org:hasUnit
Membership org:Role org:Membership org:role org:member org:organization org:memberDuring org:hasMember org:memberOf org:memberOf org:roleProperty org:headOf
Posts org:Post org:hasPost org:postIn org:holds org:heldBy
Organization change org:ChangeEvent org:changedBy org:originalOrganization org:resultedFrom org:resultingOrganization
Collaboration org:OrganizationalCollaboration

A valid use of a feature is not required to use every term listed withing that feature.

At risk features

Known implementations

Evidence that dependencies with other groups met (or not)

The ORG ontology references the PROV-O ontology (introduces a subclass of prov:Activity, recommends use of four associated properties). The PROV working group provided a Last Call review of ORG [1] and accepted [2] our disposition of those comments.

Estimated publication date

2013-05-23

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

The Working Group's charter calls for development of a standardized vocabulary for organizational structures:

Organizational Structures. Such as the Epimorphics organization ontology (see also its requirements).


The document is based directly on that prior publication as so directly addresses that requirement.

Evidence that the document has received wide review

The document is closely based on one previously released in 2010 which received wide review on the W3C egov mailing list [3].

The Last Call document received feedback from 4 commenters external to the WG, see ORG LC comments.

The number of known implementations that already exist suggest that is has received broader review and adoption than just those four commenters.

Evidence that issues have been formally addressed

Summary and detailed links on disposition of issues are given on ORG LC comments.

Objections

No objections have been raised since Last Call.

Patent disclosures

None.

The Working Group's Patent Disclosure page is: http://www.w3.org/2004/01/pp-impl/47663/status