- From: Holger Knublauch <holger@topquadrant.com>
- Date: Wed, 22 Jul 2009 18:15:12 -0700
- 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. Cheers, Holger
Received on Thursday, 23 July 2009 01:15:54 UTC