Serialization issues (Re: Policy question: Where to put comments?)

On 25 Oct 2007, at 16:03, Rinke Hoekstra wrote:

> I just posted my initial comments to:
> http://www.w3.org/2007/OWL/wiki/ 
> Structure_and_Syntax_comments_Rinke_Hoekstra
>
> The page covers sections 1-6 of the spec.

Great comments.

One thing that comes mind again is serialization issues (stimulated  
by your recurrent point about data structure vs. document structure).  
I agree with Boris (and it was borne out by implementation  
experience; Matthew Horridge tells me that the Structural Spec made  
writing the new version of the API very easy; I find the OWL API  
itself pretty easy to use) that having a common abstract APIis/ 
structural spec is a very good idea.

But I think it's helpful to have more details on the documents too.  
While many people work with tools (probably the vast majority of  
modelers), some people look at the files, or use them in a variety of  
ways. Often "enablers" (including me!) have to dip down into the file  
to see what is going on. Plus, some better stuff on the actual files  
can make so tool building, both pro and ad hoc, much easier. For  
example, I was chatting with Phil Lord about Swoop's diffing ability,  
which he liked, but he also said, "I really need it to just work in  
normal source control".

Similarly:
	http://lists.w3.org/Archives/Public/public-owl-dev/2007JulSep/0111.html

(Also note there the request for an more modern xml friendly syntax.)

I've had people tell me that they use swoop just for the serialization.

While some people do use the functional syntax directly (hi alan), I  
think a greater value is in being a common spec for many other  
syntaxes, e.g., an XML syntax, Manchester OWL syntax, or even a  
stable serialization to RDF. From the above email:

"""Protege4 (and therefore ?OWLAPI) now saves ontologies in lovely  
separated little blocks, with comments to help guide you. IMHO, it  
makes it much easier to read the ontology (which I have found useful  
when trying to debug problems)."""

So I think it would be good to add a bit *more* serialization  
details. Since we already can transform back from a looser  
serialization to a stricter one (e.g., RDF/XML to Functional) this  
wouldn't inherently constrain all serializations.

So, I suggest we make the functional syntax rather strict (e.g.,  
class axioms before property axioms before), the metamodel can be  
more abstract and elide some details in order to be a better api  
spec, and then let particular serializations inherit (or tighten)  
that strictness, or relax it, but have a clear transformation.

Please note that I've tried to provide specific evidence and  
testimony, clearly labeled with it's epistemic strength. If you would  
like stronger evidence, or evidence of a different (perhaps stronger)  
claim, feel free to ask for it, or better, try gathering it yourself.

Cheers,
Bijan.

Received on Thursday, 25 October 2007 18:47:31 UTC