Re: Propsed response to QA-WG

On Thu, 2003-06-19 at 08:18, Sandro Hawke wrote:
[...all the stuff up to here is fine...]
> 2. Regarding checkpoint 9.1 ("Indicate if the specification is
>    extensible."): this is a difficult and perhaps ill-defined issue in
>    our design space, being layered on RDF.

On the contrary: it's defined in minute detail in our spec.

I suggest in stead:

2. Regarding checkpoint 9.1 ("Indicate if the specification is
extensible."), extensibility is pervasive thruought
the OWL design.

We discuss design goals of shared ontologies, ontology
evolution, and ontology interoperability in our
requirements document.
http://www.w3.org/TR/webont-req/#goal-shared-ontologies

We discuss the relationship between OWL and RDF
in section 1.3 "The three sublanguages of OWL"
of the OWL overview.
http://www.w3.org/TR/owl-features/#s1.3

(Note this section is being edited
in response to some other comments.
The editor's current draft is at
http://www.cs.vu.nl/~frankh/spool/OWLOverview.htm#s1.3)

In appendix B of the OWL reference, we use RDFS
to relate OWL terms to RDFS terms as an example
of extensibility of RDF which can also be used
in OWL.
http://www.w3.org/TR/owl-ref/#appB

We have vocabulary to help manage ontology evoluiton:
7.4 Version information
http://www.w3.org/TR/owl-ref/#VersionInformation

OWL integrates an extensible set of datatypes;
these are introduced in the guide
http://www.w3.org/TR/owl-guide/#Datatypes1
and discussed in more detail in the OWL semantics document
  3.1. Vocabularies and Interpretations
  http://www.w3.org/TR/owl-semantics/direct.html#3.1
and 
  5.2. OWL Interpretations
  http://www.w3.org/TR/owl-semantics/rdfs.html#5.2





> 3. On checkpoint 13.2 ("Distinguish normative and informative text")
>    the Working Group feels that the style for making this distinction
>    is a matter of editorial discretion, best done with an
>    understanding of a particular document and its audience.  The
>    editors of S&AS have agreed to discuss this directly with you.
> 
> In more general feedback on your specification, there were some
> opionions within the working group that might be of interest to you:
> 
>   a.  Some people find the QA guidelines impossible to apply in a
>       useful way to their work.

I don't recall anybody saying "impossible".
I suggest

	Some members of the group found the constraints in the
	guidelines didn't look very useful. Perhaps more motivation
	or less strong constraints would work better.

>   OWL is specifically designed to be
>       useful into a future of unforseeable software systems.  Its
>       design involves techniques (model theory) which make this
>       possible but which do not necessarily mesh well with such QA
>       notions as "conformance requirements".

Strike that. Our charter calls for a formal specification largely
to *support* a clear notion of conformatce, and we've chosen model
theory as our formal specification mechanism.


>   We believe our documents
>       taken as a whole do still meet the QA guidelines, but to some
>       extent they do so as an aside, in OWL Test Cases [6]; the
>       primary specification (S&AS [3]) defines precisely what OWL is
>       without using the language of conformance requirements.

Strike that too; we do have a conformance clause for OWL documents;
it's in the test spec.


>       In particular, on conformance keywords (checkpoint 13.1), we
>       generally find "MUST is for agents" [8] a compelling argument.
>       A formal language is what it is; only processors should be
>       considered to conform in the MUST/SHOULD/MAY sense.

I don't see the relevance. I suggest striking that.

>   b.  There is also an opinion, widely held in the group, that
>       specifications and rationale should be kept separate.  The
>       public list archives provide plenty of rationale, sometimes
>       conflicting; to include that debate in the specification would
>       furthur increase its already significant complexity.

suggest adding:

Meanwhile, the issues list is an edited view of the list archives
and much of the decision record and serves at least in part
as a decision record. It is cited from the "status of this
document" at each release, and we expect it will be cited
from the ultimate Recommendation as well.

>   I'm
>       reminded of ARM [9] and AXML [10]; providing rationale is nice,
>       but is often best done off to the side for a formal language.
>       (Your rationale sections are much more important, given the
>       human context of your spec.)
> 
> I hope you find these explanations and comments useful.  I would be
> happy to continue discussion of your specifications.  Meanwhile, Karl,
> please let me know (with a cc: public-webont-comments@w3.org) whether
> this reply is satisfactory in addressing your group concerns about our
> specifications.
> 
>     -- Sandro Hawke, W3C (Semantic Web Advanced Development)
>        writing on behalf of the Web Ontology Working Group
> 
> 
> [1] http://lists.w3.org/Archives/Public/public-webont-comments/2003Apr/0064
> and http://www.w3.org/QA/2003/04/QA-Rev-owl-semantics-all
> [2] http://lists.w3.org/Archives/Public/public-webont-comments/2003May/0002
> [3] http://www.w3.org/TR/2003/WD-owl-semantics-20030331/
> [4] http://www.w3.org/TR/2003/WD-qaframe-spec-20030210/
> [5] http://www.w3.org/TR/owl-features/#s1.1
> [6] http://www.w3.org/TR/owl-test/
> [7] http://lists.w3.org/Archives/Public/www-webont-wg/2003Jun/0170
> [8] http://www.w3.org/2001/01/mp23
> [9] http://www.amazon.com/exec/obidos/tg/detail/-/0201514591
> [10] http://www.xml.com/axml/testaxml.htm
-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/

Received on Friday, 27 June 2003 13:05:02 UTC