And already have the triple about the qeii ship mar

That is, we have a sales force that covers certain ProductLines; each member travels on a regular basis, and it is useful for us to track the date of the next departure of any particular SalesPerson.

and we already have the triple about the QEII:

ship:QEII ship:nextDeparture "Mar 4, 2010".

These inferences start off innocently enough, but they become more and more counterintuitive as they go on, and eventually (when the QEII is classified as a foaf:Person) become completely outrageous (or perhaps dangerously mislead-ing, especially given that the Monarch herself might actually be a foaf:Person, causing the inferences to confuse the Monarch with the ship named after her). The asserted triples, and the inferences that can be drawn from them, are shown in Figure 6-6.

It is easy to lay blame for this unfortunate behavior at the feet of the definition of rdfs:domain, but to do so would throw out the baby with the bathwater. The real issue in this example is that we have made a modeling error. The error resulted from the overzealous urge to jump to the conclusion that two properties should be mapped so closely to each other. The ramifications of using subPropertyOf (or any other RDFS construct) can be subtle and far-reaching.

Ships:DepartingVessel

rdf:type
rdf:type
Sales:Johannes

In particular, when each of these models stated its respective domain and range statements about sales:nextDeparture and ship:nextDeparture, respec-tively, it was saying, “Whenever you see any individual described by sales: nextDeparture (resp. ship:nextDeparture), that individual is known to be of type sales:SalesPerson (resp. ship:DepartingVessel).” This is quite a strong statement, and it should be treated as such. In particular, it would be surprising if two properties defined so specifically would not have extreme ramifications when merged.

So what is the solution? Should we refrain from merging properties? This is hardly a solution in the spirit of the Semantic Web. Should we avoid making strong statements about properties? This will not help us to make useful mod-els. Should we change the RDFS standard so we can’t make these statements? This is a bit extreme, but as we shall see, OWL does provide some more subtle constructs for property definitions that allow for finer-grained modeling. Rather, the solution lies in understanding the source of the modeling error that is at the heart of this example: We should refrain from merging things, like the two notions of nextDeparture, whose meanings have important differences.