- From: Jonathan Rees <jar@creativecommons.org>
- Date: Thu, 16 Apr 2009 13:14:00 -0400
- To: ashok.malhotra@oracle.com
- Cc: "www-tag@w3.org" <www-tag@w3.org>
On Apr 16, 2009, at 11:26 AM, ashok malhotra wrote: > Did you means that the 'strict' mode would disallow or flag, for > example, use of an external library in Java or > the use of user-defined functions in XQuery or XSLT? Seems a bit > extreme to me. > All the best, Ashok OK, good point. Let me see if I can come up with a theory that distinguishes libraries from extensions. You're saying that an external library may be needed in order to process a Java program that uses the library, and that's like when an OWL processor needs to be correctly extended with a new datatype mapping in order to process ontologies that use the new datatype mapping. The difference between datatype mappings in OWL and external libraries in Java is that for libraries there is a standard way to supply a definition of one, while no such method exists for OWL datatype mapping extensions. This means that there are important questions about extension-reliant ontologies (such as entailment and consistency) that simply can't be answered automatically by OWL processors without nontrivial human intervention. With external libraries, there is a standard process to go through in order to acquire the ability to handle an "extension" - namely, you get ahold of an implementation, and put it on your CLASSPATH. This makes a level playing field for all processors of the language. OWL ontology imports work in pretty much the same way. But for OWL datatype mappings there is no such process - the spec doesn't tell you a *method* for extending the mapping, only that you can do so. The spec tells you what a "correct" implementation of an extension is, but only by delegating that question to the owner of the datatype's URI (if I understand the spec correctly). This same pattern could hold for many kinds of extension frameworks. Sometimes you don't care (the question you want to answer doesn't depend on understanding the extension); sometimes you care and you can figure it out (load the library); sometimes you care and you can't easily figure it out, and just have to say "I wish you hadn't used that extension". The last is the interoperability issue. You might even say that this distinction - methodical, mostly automatic "extension" using the same or referenced specs, vs. thought and effort required because there's no standard interface for supplying the extension to tools - characterizes the difference between a library and an extension. I'm not saying extensibility is a bad thing; I'm just asking how to engineer specs to promote interoperability. Jonathan
Received on Thursday, 16 April 2009 17:14:53 UTC