implementations and specs

I get the feeling that some of the differences between me (probably at 
one extreme) and maybe boris (for example) at another, has to do with 
the relationship we perceive between an implementation and a specification.

Several times I seem to hear Boris wanting better guidance in the 
specifications for implementors.
(The imports issue is one, the mapping rules is another ...)

My point of view is that the specifications job is to specify, and only 
to specify what is needed for interoperability, (and at least in the 
normative sections), to do no more.

I think where we know that implementators often need advice it is good 
to give some, where we can. Depending on how much effort we are prepared 
to put into reviewing such advice, it can be in informative Rec track 
document sections, or in WG Notes, or in some other form.

One of the key documents that informs my point of view is RFC 2119, that 
defines the keywords MUST and SHOULD (amongst others). It hence gives 
guidance, and indeed constrains, about writing specifications (and what 
we refer to as normative specifications).


http://www.ietf.org/rfc/rfc2119.txt

One of my favourite sections is section 6 (how sad, having favourite 
sections in RFC 2119)

[[
    Imperatives of the type defined in this memo must be used with care
    and sparingly.  In particular, they MUST only be used where it is
    actually required for interoperation or to limit behavior which has
    potential for causing harm (e.g., limiting retransmisssions)  For
    example, they must not be used to try to impose a particular method
    on implementors where the method is not required for
    interoperability.
]]

I personally would generalise that to all normative constraints, rather 
than simply those stated with MUSTs and SHOULDs

Thus I see a specification as ideally a fairly abstract specification of 
externally visible behaviour (where in the Web context, externally means 
outside my local area network), and any attempts to help tools to solve 
the many difficult problems with implementing OWL must be carefully 
worded to avoid requiring the tools to solve those problems in the same way.

I tend to see "interoperability" as a narrow concept, I think in accord 
with RFC 2119. For OWL, it amounts to can I publish an ontology using 
one tool, and read it, and reason with it, using another, and get 
results that do not surprise me. I don't think I think interoperability 
for us should include the use case of me phoning up Bijan, with us both 
looking at the same ontology in two different editors, and trying to 
have a meaningful conversation about it. If my editor and Bijan's editor 
present the ontology to us in different ways, but that as a reasoning 
tool, we don't get surprised, I am not dissatisfied.

The desired benefits are as follows:
- different tools can be different by solving the same problem 
differently. This gives choice to the end user, without sacrificing 
interoperability.
- discussions in the WG are limited to agreeing what we actually need 
for interop, rather than trying to standardize the manner in which our 
favourite tool goes about solving a particular problem

[[As an example of the latter problem, supposing I fail to convince 
people that we should avoid specifying how to do imports robustly with 
both a local copy and/or a web copy, then, since Jena provides a 
solution, I will be obliged to argue that that solution is the one that 
should be standardized. Clearly a parochial point of view, but it is in 
HP's interest, and my job is to argue HP's case.

(Also I will have to understand HP's solution, which I don't at the 
moment :(, it not being a bit of the software that has been important to 
me personally)
]]


Jeremy

Received on Thursday, 20 December 2007 12:21:51 UTC