Re: Serialization issues

How far do you want to carry this trend?  Should we define a canonical
order for the serialization of ontolgoies?  This would certainly have
some advantages (searching, diffs, source control), but also has some
drawbacks (inflexibiliy, gratuitous rejection of ontologies).  

How about having the functional-style syntax be very forgiving of order,
but having a suggested ordering?  Tools should then try to serialize in
the suggested order (perhaps with an option to not do so) but would
accept "out-of-order" inputs.

So for ontologies, the suggested order could be annotations first (in
some order), followed by imports, followed by declaration and entity
annotation then class then object property then data property then
individual axioms (each in some order).  However, the function-style
syntax would be something like

ontology := 'Ontology' '(' ontologyURI
	    	       	   { importDeclaration | annotation | axiom }
 		       ')' 

By the way, it appears that the UML diagram for ontologies is not quite
right.  Shouldn't the imports of an ontology be ontology names, not
ontologies?

peter


From: Bijan Parsia <bparsia@cs.man.ac.uk>
Subject: Serialization issues (Re: Policy question: Where to put comments?)
Date: Thu, 25 Oct 2007 19:48:42 +0100

[...]

> 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 Friday, 26 October 2007 10:11:05 UTC