Re: Draft for the response to LC comment 58 (fully typed functional-style syntax)

On 4 Mar 2009, at 14:23, Christine Golbreich wrote:

>> The W3C OWL Working Group has considered your comment and has  
>> decided that this is a very good suggestion. Therefore,
>> the functional-style syntax will be changed to be fully typed, and  
>> this will be reflected in the next version of our documents.
>> Thanks again very much for raising this important issue!
>
> Full typed syntax is  perhaps a "very" good idea for *implementors*,
> but seems a bad idea from the *user* side, as repetively said, see for
> example my email to the list [1], recalled at the F2F, and my earlier
> reply to this draft (cc to chairs).

The UML diagrams and FS are for specification and implementation  
purposes.

> Unfortunately I did not get any
> feedback.
> Seems also from Michael emails [1] that he did not find it such a
> *very* good idea either, at least from his first reaction "to deny the
> requested change".
> The decision at the F2F to switch back to full typed syntax seems to
> have been taken in big rush, without new arguments except the info
> that "Matthew  won't implement a parser in the OWL API for the untyped
> functional syntax". It is also unclear how this is related to existing
> implementations and  tools.

Many tools that plan to migrate to OWL2 use the OWL API. Pellet, P4,  
lots of custom apps.

If you want to write something in Functional Syntax, then,  
presumably, you'd like a parser for it. If you don't want to write  
something in Functional Syntax (and you don't want to write programs  
against the API), then I don't know why you care too much about it.

It's significant and important feedback.

> Until I get at least some lights why we should revise our previous
> decision to switch back to full-typed syntax, why full-typed syntax is
> prefered to mandatory declarations,  I will not agree this response.

Mandatory declarations do not alleviate, afaict, any of the user  
problems listed in your document (i.e., having to decide on the type  
of a construct before you fully know which it should be) and they  
make client code *significantly* more difficult (not just parsers).

For example:

"""Having to  decide  'some' or 'all' is already not always trivial for
users designing applications, having to select a 'type' (object/data)
in addition, makes it even more penalizing.  If it is decided to
impose the burden of fully typed syntax to users, would it not be then
cleaner from a specification viewpoint to rather impose mandatory
declarations ?"""

The right solution here is to have good refactoring tools, not to  
muck with the internal api or, too much, with the concrete syntax.  
After all, you already have to make upfront decisions with respect to  
Some and All which are *much* more difficult to detect and repair  
than using an object vs. a data property.

Ontology builders are not the only users we must cater for. People  
building custom applications that use ontologies are a critical  
audience as well.

Cheers,
Bijan.

Received on Wednesday, 4 March 2009 14:42:19 UTC