- From: Jeremy Carroll <jjc@hplb.hpl.hp.com>
- Date: Mon, 17 Feb 2003 12:18:52 +0100
- To: "Sean Bechhofer" <seanb@cs.man.ac.uk>, "Jeremy Carroll" <jjc@hplb.hpl.hp.com>
- Cc: "WebOnt WG" <www-webont-wg@w3.org>
> I think I've perhaps conflated (at least) two issues in my earlier > email. I'd (probably) be happy to live with a situation where I have > to infer the types of things -- for example above with the property > p. In this case, a tool can always inform the user of the assumptions > it is making. However, the issue of splitting expressions across > different ontologies still concerns me. I have difficulty in understanding which expressions can be split. In the current mapping rules I see: - rules which have a blank node as the main node These can't be split, because blank nodes are local to a single RDF/XML document - rules which have a uriref as the main node. These can be split in both the concrete and abstract syntaxes, and the tools you are talking about need to cope with this scenario. - my pet hate rule for DisjointClasses which can be split e.g. DisjointClasses(unionOf(<a>,<b>),<c>,<d>,unionOf(<e>,<f>)) creates six owl:disjointWith triples between four nodes, two of which are blank. If the five triples involving the blank nodes are all in one file, with the sixth triple in a second file, then you have a point. But the moral is not that we need to reopen imports, but that we need to fix that rule. My suggestion is that we delete the mapping rule and find some other solution. I have presented such an approach in detail. With Peter's latest changes (see current editors draft) the other rules I think either can be reduced to pairwise expressions in the abstract syntax or necessarily must remain in a concrete syntax file because of the locality of blank nodes. > > In my opinion, it makes things *much* cleaner if I can at least decode > the triples into some other data structure which is closer to the > abstract syntax before processing them. And in particular do this > "locally" within each ontology. With the exception of DisjointClasses you can. > > Peter's redefinition: > > [[ > DEFINITION: An RDF/XML document is an OWL DL ontology if > > 1/ the RDF graph resulting from parsing it as an RDF/XML document forms > the > translation of a single OWL ontology in the abstract syntax; > > 2/ all RDF/XML documents that it imports are also in OWL DL ontology form; > > and > > 3/ the imports closure of the document > > a/ does not use any URI reference as more than one of an ontology name, > a classID, a datatypeID, an individualID, a datavaluedPropertyID, an > individualvaluedPropertyID, or an annotationPropertyID; and > > b/ does not use any of the URI references from the RDF, RDFS, or OWL > namespaces that are mentioned in the RDF or OWL semantics except for > the OWL datatypes, the OWL built-in classes, and the OWL built-in > annotation properties. > ]] > > would, I think, alleviate my concerns. The definition seems to be > silent regarding the requirement for everything to be typed, > though. Is this deliberate? > A particular test case would be: FileA: <p> rdf:type owl:DatatypeProperty . FileB: <p> rdf:type owl:ObjectProperty . FileC: <FileC> owl:imports <FileA> . _:a rdf:type owl:Thing . _:a <p> "foo" . FileD: <FileC> owl:imports <FileB> . _:a rdf:type owl:Thing . _:a <p> "foo" . FileC is in OWL Lite whereas FileD is in OWL Full. The type triples end up as fairly important. Jeremy
Received on Monday, 17 February 2003 06:19:09 UTC