Proposal Re: B.1, B.2

This message summarizes the options and gives fall-back positions, and has 
a proposal that I hope the chairs will give 5 minutes to before the LC vote 
tomorrow. I will withdraw this proposal if Peter opposes. One technical 
detail is left to an appendix at the end of the message.


Options
=======

Problem Statement:
How should the proposed recommendation map DisjointClasses and 
EquivalentClasses with more than two components from the abstract syntax to 
the concrete syntax.


Plan A:
Proposal B.1, B.2 from the editors meeting, original made by Peter.
With a correct proof. Using current mapping rules.

Plan A-:
Proposal B.1, B.2 from the editors meeting, original made by Peter.
Without a complete proof. (i.e. the proof is basically as is, and it is 
noted that we failed to finish it due to time pressure).

Plan B:
The current text - with sufficient conformant implementations.

Plan B-:
The current text - fudging that implementations diverge from it.

Plan C:
One of my earler proposals, specifically that these should be mapped by 
structure copying. Effectively the concrete syntax is limited to the case 
that n=2 (see appendix for mapping rules).


As I understand it -
   Plan A is universally preferred.

Our options for last call are plan A- or plan B.

Risks
=====

A risk analysis is:

plan A- at LC
   risk that the proof is not possible with the effort that anyone in the 
group is prepared to put into it.

fallback options for plan A- at PR:
    plan A-  at PR
      risk that the result is actually false
    plan B at PR
      unlikely that there would be implementations if we don't have it in LC
      risk that we may have to delay PR in order to seek implementations.
    plan B- at PR
      failing to implement part of our rec is a risk
    plan C
      not popular with group, similar risks of delay


plan B at LC
   risk that we will not be able to fully articulate what implementors need 
to do; risk that they won't do it anyway (it is intricate and not cost 
effective in implementors time); risk that we put additional unnecessary 
cost on OWL implementors and users (assuming plan A is in fact feasible).

   fallback options for plan B at PR:
    plan B- at PR
        puts rec at risk as above
    plan A, A- at PR
        risk of delay as above
    plan C
        not popular, risks of delay


I don't think I can quantify any of these risks - other than to say they 
are all non-trivial. The risk minimization path would be to delay, but I am 
sure I would in a minority of one if I suggested that!

My preference is plan A- at LC aiming for plan A at PR. If the proof is too 
difficult I think we should then choose between plan A- and the other 
options depending on technical judgement given the nature of the 
difficulties with the proof.

We currently have plan B aiming for ?guess? plan B at PR.


Proposal
========

I propose that we reopen DL Syntax 5.26:
   - resolve it as in [1] (including B.1 and B.2),
   - give the S&AS editor discretion to add text, for example as in [2], to 
make these changes,
   - and further discretion to add (or not) text as in [3] to articulate DL 
and Lite graphs as triples,
   - and then close the issue again.


(Note the process document specifically grants the chair the descretion to 
reopen an issue in light of input from someone who was not at the telecon)

Refs:
====
[1]
http://lists.w3.org/Archives/Public/www-webont-wg/2003Mar/0066.html
[2]
http://lists.w3.org/Archives/Public/www-webont-wg/2003Mar/0183.html
http://lists.w3.org/Archives/Public/www-webont-wg/2003Mar/0184.html
[3]
http://lists.w3.org/Archives/Public/www-webont-wg/2003Mar/0161.html
http://lists.w3.org/Archives/Public/www-archive/2003Mar/att-0073/m


Appendix - Mapping rules for Plan C
===================================

These *copy* the relevant descriptions, hence reducng the complexity of the 
concrete syntax in the opposite fashion to the B.1 B.2 approach.

Replace:

DisjointClasses(description1 ... descriptionn)
=>
T(descriptioni) owl:disjointWith T(descriptionj) . OR
T(descriptionj) owl:disjointWith T(descriptioni) . 1=<i<j=<n
T(descriptioni) owl:disjointWith T(descriptionj) . [opt] 1=<i!=j=<n

and

EquivalentClasses(description1 ... descriptionn)
=>
T(descriptioni) owl:equivalentClass T(descriptioni+1) . 1=<i<n
T(descriptioni) owl:equivalentClass T(descriptionj) . [opt] 1=<i,j=<n

with

DisjointClasses(description1 ... descriptionn) n > 2
=>
T(DisjointClasses(descriptioni descriptionj))  1=<i<j=<n
T(DisjointClasses(descriptioni descriptionj))  [opt] 1=<i!=j=<n

DisjointClasses(description1 description2)
=>
T(description1) owl:disjointWith T(description2) . OR
T(description2) owl:disjointWith T(description1) .

and

EquivalentClasses(description1 ... descriptionn) n > 2
=>
T(EquivalentClasses(descriptioni descriptioni+1)) 1=<i<n
T(EquivalentClasses(descriptioni descriptionj))  [opt] 1=<i,j=<n


EquivalentClasses(description1 description2)
=>
T(description1) owl:equivalentClass T(description2) .


No other changes anywhere (except in the graph as triples section - I have 
some text for this somewhere).




Jeremy

Received on Wednesday, 26 March 2003 04:32:42 UTC