- From: Timothy Redmond <tredmond@stanford.edu>
- Date: Wed, 18 Feb 2009 11:30:44 -0800
- To: Bijan Parsia <bparsia@cs.man.ac.uk>
- Cc: Ian Horrocks <ian.horrocks@comlab.ox.ac.uk>, "Peter F. Patel-Schneider" <pfps@research.bell-labs.com>, Alan Ruttenberg <alanruttenberg@gmail.com>, public-owl-wg@w3.org
I wanted to be sure that I understood where things stand with this issue. It seems to me that XML Catalogs can be used to satisfy the use cases that I have. (I have another use case where XML Catalogs would also seem to work). But this only works if a critical mass of the tools adopt or at least support this mechanism. For example, I know a group that has users who check ontologies out from svn and edit them. This group of users all favor different tool sets and I think that one of their challenges is getting these tools to work nicely together. Putting an XML catalog in svn will only help if TopBraid, OntoEdit, Protege 4, etc all can read this format. Having different repository formats for different tools is the status quo and is awkward. Also, a person using the pellet tool may have trouble if the pellet tool does not understand where his ontologies live. (I have also had this problem with owl syntax validators.) In the use case example that I give below, the XML Catalog is only useful if the ontology api in question can use the Catalog. So my question is, do the other members of the working group feel that XML Catalogs are an acceptable compromise or solution? If so is there some way that the owl working group can encourage tool builders to use XML Catalogs? Or would we recommend low level mechanisms that redirect the URL based IO independently of the tool set? -Timothy BTW - Here is another use case (from one of my past lives): I have another use case which may be useful. In many cases applications cannot trust or depend on the internet. If the application in question is a java application, then it makes sense that the ontologies in question probably live in a jar file. Since Java can find resources through URL's (it uses jar:file:--path--!--path-- ) one could put an XML Catalog in the jar file as a resource and use this to redirect the ontology references. This depends on an assumption about the jar class loaders and I am not sure if this is documented. But it looks likely that this approach would work with the current Java implementations. At the time I solved this problem with a low level intercept, URL.setURLStreamHandlerFactory, but it is not clear that this was a very good idea. On Tue, 2009-02-17 at 11:51 -0800, Timothy Redmond wrote: > >> > > >> Does this meet your concern? > > Yes I think that it does. Thanks Bijan (and all). > > -Timothy >
Received on Wednesday, 18 February 2009 19:31:30 UTC