Handling multiple rdfs:ranges

Hi All,

I'm wondering if many people here use multiple rdfs:domain/rdfs:range
properties in RDF Schema?

The RDF Schema spec is clearly worded: "Where P has more than one
rdfs:range property, then the resources denoted by the objects of triples
with predicate P are instances of *all* the classes stated by the
rdfs:range properties." [similarly for rdfs:domain]

However, this doesn't quite match the usage of multiple
rdfs:domain/rdfs:range properties in several popular datasets.

For example, in Bioportal, the property bpo:has_event has three classes
indicated as its domain: bpo:person, bpo:event and bpo:disease_or_disorder.
Following the wording of the spec, it would appear that any resource that
appears in the subject position of a triple with property bpo:has_event is
an instance of all three types bpo:person, bpo:event and
bpo:disease_or_disorder. However, common sense says that the resource
cannot simultaneously be a person, event and disease.

Elsewhere, the provenance ontology avoids the problem by explicitly using
owl:unionOf. For example, prov:wasInfluencedBy has rdfs:range such that it
is the owl:unionOf the classes prov:Activity, prov:Agent and prov:Entity.
DBpedia avoids the problem entirely, since I cannot find any multiple
rdfs:domain/rdfs:range properties in their ontologies.

The interpretation of multiple rdfs:range properties in the above datasets,
either implicitly or explicitly imply an alternative spec such as:

  "Where P has more than one rdfs:range property, then the resources
denoted by the objects of triples with predicate P are instances of *some*
class stated by the rdfs:range properties."

I'm wondering whether anyone else has observed this mismatch between the
spec and real world datasets; and what the official line would be on
avoiding this conflict?

Regards,

Ross


Note I'm using the following prefixes in examples:
bpo: <http://www.semanticweb.org/ontologies/2010/10/BPO.owl#>
prov: <http://www.w3.org/ns/prov#>
rdfs: <http://www.w3.org/2000/01/rdf-schema#>