W3C home > Mailing lists > Public > public-owl-wg@w3.org > November 2007

Re: UFDTF Metamodeling Document

From: Bijan Parsia <bparsia@cs.man.ac.uk>
Date: Fri, 30 Nov 2007 15:05:24 +0000
Message-Id: <B0A1D2BE-75EF-47B8-A359-D8E6317696A7@cs.man.ac.uk>
To: OWL WG <public-owl-wg@w3.org>

On 30 Nov 2007, at 10:19, Boris Motik wrote:

> Hello,
>
> I would like to second Peter's sentiment, and would like to give  
> some concrete explanation why this is so. All sound and complete
> reasoners for OWL DL that are currently out there do not use RDF- 
> based storage. Similarly, ontology APIs that are designed to work
> with OWL DL, such as (Manchester) OWL API and KAON2, are likewise  
> not based at all on RDF, but on a storage mechanism that is quite
> close to the metamodel presented in the structural specification  
> document. In these tools, RDF is used just as an exchange syntax.

Having tried to do OWL stuff directly on RDF (back in the day), I  
will say that it imposes a cognitive/development burden on me that  
I'm not willing to accept. Thus, services like:
	justification finding
	diffing
	pretty printing
	modularity analysis, segmentation, etc.
	ontology complexity analysis
	normalization
are things which, thus far, most significant (that I know of)  
theoretical, algorithmic, and implementation work has taken place at  
the axiom level. Indeed, a major reason for killing off the frame  
style stuff in the functional syntax is that that *got seriously in  
the way* when reflected down into the OWL API (it still might be ok  
for certain presentational purposes, natch).

Many editors work at the axiom rather than triple level. The only  
serious focused-on-OWL editor for which I've seen a claim that this  
is *not* the case is TopBraid Composer. Unfortunately, it's closed  
source so I can't really tell you how it works inside. I struggle to  
imagine how it works except by having some higher level structures/ 
object model.

Other people may have different experiences, but this is my  
experience and that of many the developers I've collaborated and  
chatted with. Obviously, there are cases where the triple  
representation and the higher level representation coincide or are  
very close...take subsumption between atomics. Then it really  
*doesn't* matter. But for anything moderately complex, esp. complex  
expressions (by which I just mean expressions :))

I have *no idea* how any of this affects or should inform the OMG  
work. I was solicited to review that work some months back, but I had  
neither time, nor energy, nor, I believe, relevant expertise. (I  
still struggle with what all this does or doesn't help me/allow me to  
do or what good practice is. I tend to think of "metamodels" as  
grammars in which case I have trouble understanding why I should pay  
attention to a particular grammar presentation.  Elisa has helped me  
in private email, but I think it will take a while before I can  
comment usefully on the details.)

I do think a fairly high level presentation is useful. I also, as  
I've said before, think more concrete specification in serialization  
would be helpful. For me, specs in terms of triples are not  
particularly useful (if only since I deal with many syntaxes other  
than triple based ones).

I wrote this merely to provide information. I don't yet recognize  
that I have stake in keeping the diagrams or metamodel in W3C or not.

Cheers,
Bijan.
Received on Friday, 30 November 2007 15:04:00 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:13:27 GMT