Property Proliferation Control

In the current OWL 1.1 specification, the RDF realization of the langauge will contain a large number of terms related to declaring the type of various properties. These are primarily needed to make parsing of OWL/RDF documents easier, esp. when there are imported ontologies. The set of new terms related to this in OWL 1.1 include at least (since there is no definitive list at this time, it is hard to tell):

• owl11:FunctionalDataProperty
• owl11:FunctionalObjectProperty
• owl11:equivalentDataProperty Disambiguation for EquivalentProperties axiom
• owl11:equivalentObjectProperty
• owl11:subDataPropertyOf Disambiguation for SubProperty axiom
• owl11:subObjectPropertyOf
• owl11:dataPropertyDomain Disambiguation for domain construct
• owl11:objectPropertyDomain
• owl11:disjointDataProperties
• owl11:disjointObjectProperties
• owl11:inverseObjectPropertyExpression
• owl11:FunctionalDataProperty

Some possible ideas for dealing with these in the RDF realization

• • Have a way of declaring which properties are in an ontology (could include classes as well) - this was actually suggested in OWL 1.0 early on, and we never returned to it - but for example, the owl:ontology property could be made useful by letting it have a class-list and a properties-list which is a list of all classes/properties in an ontology. This would have the nice feature like making it possible to take a large ontology, like NCI, and describe a subclass of it with its own name. Boris believes this ability to know the coverage of an ontology would make these typing terms less needed.
  • Develop an RDF-based langauge construct where one could include keywords in a property definition- so when the property is declared, just as we can include range and domain, we could include some property modifiers. This doesn't really remove these terms from the language, but it lets us add them in a way that is somewhat less intimidating to the user considering OWL with little or no background in KR
  • Do some namespace engineering that defines these things logically in the OWL11 namespace so that some of these things can be easily deduced by the parser. So if I know that something cannot be both a dataProperty and objectproperty at the same time, then I can know that if Y is a subproperty of X, and X is a datatype property, then Y can never be an objectproperty - and thus we would not need subObjectPropertyOf and subDataPropertyOf

We note that although these are issues having little or no semantic import in and of themselves, language design is a bit of an art, and simplification is generally considered an important aspect of that art. (we note that the first solution is more fundamental than the other two, but it not only solves this problem, but others as well, so we include it here)