- From: Jeremy Carroll <jjc@hpl.hp.com>
- Date: Thu, 14 Feb 2008 14:00:40 +0000
- To: "Web Ontology Language ((OWL)) Working Group WG" <public-owl-wg@w3.org>
- CC: www-qa@w3.org
Concerning ACTION-89 The document I had in mind was: http://www.w3.org/TR/spec-variability/ I think the introductory text is well worth consideration e.g. [[ As a general principle, variability complicates interoperability. In theory, interoperability is best when there are numerous identical, complete, and correct implementations. However, when compared to the alternatives, the net effect of conformance variability is not necessarily negative in all cases. For example profiles — subdivisions of the technology targeted at specific applications communities — introduce variability among implementations. Some will implement Profile ABC, some will implement Profile XYZ, and the two might not intercommunicate well if ABC and XYZ are fairly different. However, if ABC and XYZ are subsets of a large monolithic specification — too large for many implementers to tackle in total -- and if they are well targeted at actual application sectors, then subdivision by profiles may actually enhance interoperability. Different sorts of variability have different negative and positive impacts. The principal danger is "excessive" variability - variability that goes beyond what is needed for a positive interoperability trade-off and that unnecessarily complicates the conformance model. Specification editors need to carefully consider and justify any variability allowed and its affect on conformance. This can be done by referencing project requirements and use cases and/or explicitly documenting the choices made. ]] The whole thing is fairly concise and worth a read in my view. In terms of the discussion we were having yesterday, I think that if there is substantial vendor interest in a particular fragment then that should provide adequate positive impact to counter the negative impacts - but that having too many fragments is likely to have the opposite effect. Jeremy
Received on Thursday, 14 February 2008 14:01:11 UTC