[This has been superceded by OWLED task forces.
One main difference is that the tripartite structure proved to be too
unweildy at OWLED 2007, so basically we just ahve Mature and Everything
Else (i.e., Specs and Reports).]
[Work in progress. Please send suggestions to Bijan Parsia. This is not anything binding, but just a proposal.]
Given the necessarily limited time at an OWLED for discussion and informed decision making, it is important that we have some idea of what we can accomplish and how at a meeting. Much of the work on OWLED generated specification necessarily takes place between events. This document proposes a process that allows for effective, distributed, minimal coordination of such work (on the one hand) and effective decision making about that work at OWLED meetings.
The concrete outcomes of OWLED are documents which specify something related to OWL. The canonical example is an extension or change to the OWL language, whether its syntax or its semantics. OWL 1.1 is an example of such a (collection of) specification(s). OWL 1.1 was partially determined by whether it would actually change the state of the deployed art...that is, whether the implementors would actually implement it. Without a document in hand, it is very difficult to decide, as a group, at an OWLED, whether we "endorse" some proposal. On the other hand, there hasn't been a mechanism for new proposals to be recognized in a non-ad-hoc way. This has not been a problem so far since we've been working on OWL 1.1. But we need a new way forward.
Aside from papers, OWLED should accept proposals for consideration and discussion. Given the scarcity of OWLED time, at an OWLED a community should communicate to interested people what work they'd like to consider at the next OWLED. There are three levels under which a proposal may be presented at an OWLED:
For a standardization session, the OWLED general chair will solicit proposals for a report. The champion of that proposal will be given time to present their arguments that the general area is ripe for OWLED consideration (e.g., there are clear and widespread use cases with users advocating them and there is enough robust work that it's plausible that that standardization is possible in the subsequent few years). After the presentation and discussion, the attendees will be asked if they would like to see a more formal report at the next OWLED. The report will summarize the state of the art on that topic and make a recommendation as to what is worth trying to standardize.
If after the report, it is clear that there is something which:
the OWLED community may decide to ask for volunteers to flesh out the recommendation into a spec for consideration at the next OWLED (and, of course, for general mailing list discussion).
At the subsequent OWLED, the volunteers will present their proposed spec (after having solicited community feedback all along and having a reasonably mature version of the spec for review a month before the meeting). If there are already implementation (at least two) and widespread support and the community considers it "ready", then the community can decide that that spec will be submitted to a standards body (typically the W3C) with the intention of pursing standardization of that spec. Otherwise, the community can decide that it is not ready to pursue formal standardization. There are a number of reasons for this. If the spec isn't quite ready in the community opinion, but promising, they can as the volunteers to present it again at the next meeting and for implementors to commit to (trying to) implement it for that meeting. The community may decide that its the wrong approach and rethink things. Or, perhaps, the community might decide that the spec is perfect, but, say, because of resource issues, its better to keep it a de facto standard, rather than pursuing a de jure one at that time.
For OWLED 2007, I think SPARQL/OWL (at least, conjunctive abox query with variables in the predicate position, but also restricted mixed TBox/ABox queries) is ready to request a submission ready spec for the next OWLED. We know how to do it. There are multiple implementations. SPARQL is hot and about to reach recommendation status. The working group is not going to take on that work (and can't, by its charter). And it is being heavily used, even on OWL and people want to use more. Even a W3C member submission would be enough to do a great deal of good for OWL.
DL Safe rules are fairly well understood, but there's only one really robust implementation at the moment (in KAON2; there's an experimental implementation in Pellet). They are easy to specify (at least the core) and there is a fair amount of desire for rules of some sort, and for features that could be usefully subsumed by DL Safe rules (e.g., inverse functional properties on datatypes for named individuals only). However, there are extra features one could add (builtins, SPARQL like higher order features), and some alternatives (e.g., non-monotonic description logic programs). So, it makes sense to request a spec for discussion at the next OWLED. (Of course, if it catches fire, we can adjust).
Temporal features are clearly important with users increasingly requesting them (I've had several people request this for the OWL 2.0 space). But there are lots of possibilities and few worked out proposals and implementations (as an extension to OWL). So, it would make sense at this OWLED to solicit volunteers to generate a report for the next OWLED. This could consist of motivating use cases, decision trees explaining tradeoffs, solicitation of prototypes, etc.
In a blog post, I described a slightly different taxonomy for features and proposals, simplifying and generalizing it a bit, we have:
In order to faciliate participation and predictability, we should:
This
isn't
meant to be a rigid process, but a way of organizing things. It's meant
to help provide some predictability and even more transparency. If
someone shows up at an OWLED with a worked out spec and a bunch of
implementation support, hurrah!