ORG futures

As noted noted on Friday I find the agreed approach to CR exit 
confusing, complex and unconvincing. It's just the best we could find.

For Data Cube we will take a different approach because we have strong 
notions of well-formedness there (this was in IRC but I want to make 
sure it is clear).

So the question I've been thinking about is what to do about ORG. I see 
a few of options so far:

1. Just do it

Go ahead with the agreed approach. Put the time into trying to create a 
sufficiently good set of probe queries and evaluation checklist, and 
find a way to explain them clearly. It will take non-trivial work to put 
this together in a form that would be understandable and convincing at a 
transition meeting and would be understandable to implementers.
It might be doable, I've not yet ruled this one out.

2. Profiles

As part of the exit criteria we define a few profiles of ORG (e.g. core, 
memberships, history). We put everything not in the core profile at 
risk. We define a set of conformance tests for the profiles which 
include genuine tests[1] and probe queries (no separate checklists). 
Our criteria are that each profile should have two implementations that 
pass the tests and pass inspection-by-probe [2]. Oh, and presumably 
still have each term in the profile have two examples of usage.

This approach would give us a structured way to exit without complete 
implementations. By having constrained profiles we might be able to do 
stronger tests which means that we could rely on the tests more. It's 
more work than #1 but at least the work might feel useful.

3. Publish as a Note

Vocabularies are not software and they need not be schemas. In semantic 
web open world style they are modular things you can pick and choose 
bundles of terms from. ORG provides a useful bundle of terms for 
organizations which demonstrably fill in gaps and people are finding 
useful. However, we are not yet ready to define schema-like 
interoperability criteria for it. So stop battering out heads against 
the REC track brick wall and simply walk through that tempting "make it 
a Note" door.


So some clarifying questions:

(a) What's the constraints on marking things "At Risk" at CR stage. Can 
we mark things "At Risk" which weren't marked that way at Last Call?

(b) Would it be OK to have specific bundles of features in the CR 
criteria?  We defined a notion of profiles at Last Call but obviously 
didn't list any profile sub-sets of ORG itself.

(c) How problematic would it be if we moved ORG to a Note?

Dave

[1] These are implicitly going to making stronger closed-world 
assumptions than the vocabulary strictly requires. This is in the 
interests of jumping the "can test interoperability hurdle", not an 
actual constraint on how people in general can use ORG.

[2] Might want present the probe queries as a test consuming 
application, that would be easier to explain.

Received on Saturday, 13 April 2013 07:53:14 UTC