W3C home > Mailing lists > Public > public-owl-dev@w3.org > July to September 2009

Re: owl.owl (was: OWL 2 -- Call for Implementations, new Drafts)

From: Holger Knublauch <holger@topquadrant.com>
Date: Wed, 22 Jul 2009 18:15:12 -0700
Message-Id: <3159BAB6-59AF-47D1-92BC-7A76B6B5A646@topquadrant.com>
To: public-owl-dev@w3.org
Hi Bijan,

thanks for your very balanced response :) I appreciate that you  
understand where I am coming from, and I certainly also understand  
your view point. I don't want to respond to every single detail - this  
would just lead to an endless thread, and we all have work to do.

I agree that we need to make clear that people do not (again) start  
importing the owl.owl file into their domain models. This problem  
already exists because the current OWL namespace file is already  
there. So the question remains of what the OWL 2 working group will do  
with the old OWL.owl file. Either update it or drop it. Since it's a  
low hanging fruit, and since it makes life easier for many people  
(including myself and developers of any generic linked data browser or  
query tool) I don't see strong arguments against keeping an OWL (2)  
file there. The concerns that you seem to have are mostly "soft"  
issues such as educating people that this is not really a spec but  
just a set of RDF triples to describe the vocabulary. This appears to  
be very doable though.

Instead of owl:importing it, my assumption is that many semantic web  
tools will already have the OWL (and RDFS) namespaces somehow built- 
in. In TBC we solve this using an implicit sub-graph that is  
automatically included into the display graph. We then have a list of  
URIs that are hidden in the class and properties trees by default, in  
particular some system properties that are really not meant to be used  
directly, such as owl:hasValue. For OWL 2, I will simply need to  
extend this list of properties and classes so that the UI does not get  
cluttered. This is minimal work.

There are several places where having the OWL triples is very helpful  
as it provides a basic skeleton. My usual example is the class tree  
structures where traversing the rdfs:subClassOf triples of the  
metaclasses is very useful. Overall the system triples make our code  
base much more model-driven and consistent. The price for this general  
solution is, as you state, that sometimes the generic solution is not  
enough and custom widgets, parsers or renderers are needed. This is  
particularly the case for blank node structures such as OWL  
restrictions. We have hard-coded some special handling for these into  
our tool, using a plugin mechanism. I will need to see in detail which  
new OWL 2 constructs require this, but from what I can tell so far  
there won't be a need to add much. At least, people can "see" and  
navigate to all OWL 2 resources consistently, including getting  
statistics (which simply could instances of each class including the  
metaclasses). Other tools may have different approaches to this, with  
more special handling of OWL constructs, but our starting point has  
been RDF(S) and so far this has been a very good choice (for us).

One of the places where I needed to hard-code against OWL vocabulary  
was to find "relevant" properties, i.e. the properties that shall by  
default show up on an instance form. With RDF(S) only, this would  
include all properties that have the type of the instance in their  
domain. With OWL, we also look for locally defined OWL restrictions. I  
may need to add a bit of that code for the new OWL 2 features, but the  
bulk of work has already been done for OWL 1. But other than that, you  
may be surprised of how little the OWL vocabulary is actually used in  
our code base. That's why - from my experience - we can treat OWL  
almost like any other ontology such as FOAF. Just like FOAF, OWL  
should therefore also have a vocabulary file at its base URI.

So overall, the OWL.owl file will help getting tools like ours  
started. We need to see what the hidden extra costs of adding OWL 2  
support will be, and this was also one of the points raised by earlier  
responses from TQ on OWL 2. People may gradually expect more and more  
"native" support for OWL 2 features and this might become a nightmare  
to support, especially given the huge number of OWL 2 features. We'll  
see how it goes once we start adding some OWL 2 support.

Received on Thursday, 23 July 2009 01:15:54 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:58:18 UTC