Re: WebOnt review of QA guidelines

Here is a quick review of


I did not find this document helpful.
It seems to address specs in mature fields rather than areas that are still in 
A lot of the priority 1 items either seem obvious or irrelevant (overly 


It expands on the checklist found in:

To exemplify why this document is not helpful I will go through the priority 1 
items with ref to WebOnt and RDFCore documents

1.1 Include the scope of the specification.
[Priority 1]
Not every rec in the multi-document recommendations does this. It probably 
doesn't matter, as long as together the scope is clear.
2.1 Identify all classes of product.
[Priority 1]
Both RDF and OWL documents and WGs have avoided doing this, on principle. 
Neither technology is sufficiently mature to make this a useful task.

2.2 For each class of product, define the conformance requirements.
[Priority 1]

RDF has eschewed conformance statements. For OWL we decided to define 
conformance statements for documents and for two classes of idealised 
processors which I do not believe will exist in practice.  [For example, we 
defined an "OWL Syntax Checker" - I have written one, but it, by itself, is 
not hugely useful - more useful functional can be built on top of it, by 
being encouraged to conform however, my useful functionality built on top 
will interoperate with X's useful functionality built on top of X's 
conformant (but equally useless) OWL Syntax Checker]

3.2 If special conformance terms are used, include a definition in the 
[Priority 1]
Again "in the specification" needs to be aware of multiple document 

3.3 Justify any usage of a dimension of variability
[Priority 1]

The OWL documents as a whole do this - but for instance the OWL Test document, 
which contains the conformance statements, does not. 

4.1 Indicate whether or not the use of profiles is mandatory for conformance.
[Priority 1]

Hmmmm "profiles???"
This seems to correspond to the OWL Lite, OWL DL, OWL Full sub-languages ...
Our conformance statements in
are clear in their relationship with these sublanguages without "Indicat[ing] 
whether or not the use of profiles is mandatory for conformance." So 
minimally these seems poorly phrased.

Basically I think OWL does alright here, yet does not meet this requirement. 
So the requirement seems faulty.

5.1 If modules are chosen, indicate any mandatory conditions or constraints on 
their usage.
[Priority 1]
I don't think we have modules ... 
7.1 Identify each deprecated feature.
[Priority 1]
Not done in OWL (first version no legacy).
Not sure about in RDF, unqualified attributes comes to mind.

7.2 For each class of product, specify the degree of support required for each 
deprecated feature and the conformance consequences of the deprecation.
[Priority 1]

7.4 Include an explanation for the deprecation.
[Priority 3]

Including lots of ratrionales can make the text too long and unwieldy. Better 
to have public WG e-mail lists - then the rationale is world visible. Keep 
the documents clean - never apologize, never explain.
8.1 State the circumstances for when discretionary items are allowed
[Priority 1]
There is a small amount of this done in RDF semantics (discussion of semantic 
extensions) - however both OWL and RDF are foundational and allow things to 
be built on top - any of this building on top is discretionary - there seems 
to be a general rule that such building on top should be monotonic ...
Exactly which datatypes are required seems unclear ...

8.2 For implementation dependencies, address the allowable differences between 
[Priority 1]
Conformance requirements: the specification MUST describe any permitted 
variations or constraints for how the implementation dependency is realized 
by implementations.

Examples of permitted variations or constraints to be addressed include:

implementation dependent ranges, data, minimum or maximum values,
environmental resources (e.g., memory or disk limitations),
environmental values (i.e., language and local settings).
we don't do that - yes these things impact implementations, and so? - we can't 
say anything useful, and so we don't waste our breadth.

9.1 Indicate if the specification is extensible.
[Priority 1]
9.2 If extensions are allowed, define their scope and constraints.
[Priority 1]

9.3 Prevent extensions from contradicting the specification.
[Priority 1]

10.1 Include a conformance section.
[Priority 1]
Again, in a multidocument publication this may only be in one document.
I don't have much problem with RDF not having this. 

11.1 Identify and define all conformance designations.
[Priority 1]
OWL did this, RDF did not (well unless you count the empty set, but then 
people, including myself claim conformance to RDF)

11.4 Impose no restrictions about who can make a claim or where claims can be 
[Priority 1]
OK we didn't ...

13.1 Use conformance key words.
[Priority 1]
I find connolly's
"MUST is for agents" discussion compelling.
Thus the conformance keywords should not be used except for agents.

13.2 Distinguish normative and informative text.
[Priority 1]
Both groups have been doing this.

13.3 Use consistent terminology.
[Priority 1]
Easier said than done.
Both groups try to do this.

My browser when faced with
gets a redirect to
and loses the frag ID, I don't know if this is a browser problem or a document 

It seems odd to have a recommendation with lots of points when the CR exit 
criteria did not require any implementation of all of them.

I think WG will pick and choose out of this list.



Received on Thursday, 24 April 2003 16:24:01 UTC