- From: Smith, Michael K <michael.smith@eds.com>
- Date: Fri, 20 Sep 2002 13:56:09 -0500
- To: Webont <www-webont-wg@w3.org>
I just thought I would put forth a straw man importing solution that is the most trivial I can imagine. It is in the class of solutions that do not make the ontology name and its relationships part of the ontology. - Mike Consider a purely syntactic #INCLUDE-like mechanism, out of the scope of any enclosing OWL/RDF. Owl:include doesn't mean anything, formally. Its a pre-processing directive. We do need to deal with loops, which languages like C punt on. <owl:include import="uri1" /> <rdf:rdf ...> ... </rdf:rdf> Let UriSet be the transitive closure of the imported uri's in the document. For all urin in UriSet, Insert the rdf:rdf elements of those uri's, modified by the addition of an xml:base="urin" attribute/value to the rdf:rdf tag. E.g., for each urin add <rdf:rdf xml:base="urin" ... > ... </rdf:rdf> There is no restriction on RDF that says there can only be a single rdf:rdf element in a document, so this would seem to work. It does mean that we need to import ALL rdf:rdf elements contained in the target uri. If you want your RDF processor to work with this mechanism you would need to modify it to honor the imports and handle xml:base. But as far as I can see, any solution to imports is going to require some mods to your RDF processor, except perhaps if we go with XInclude. (Recent messages suggest even that is optimistic.) Which is the main attraction of XInclude, but I am concerned that that standard is too restrictive. If we are willing to accept the no-cycles restriction of XInclude then we could probably use it. Particularly in this simple case where we are assuming it is not imbedded within RDF. I confess to having trouble making sense of the differences between inclusion restrictions and loops in the XInclude standard when 'parse="xml"' vs 'parse="text"'. It looks like the text case is not recursive with respect to XInclude and the xml case considers loops and ill-formed XML a fatal error.
Received on Friday, 20 September 2002 14:58:21 UTC