Just to further elaborate on the example: If we assert:
dwc:HumanObservation rdfs:subClassOf dwc:Event.
and then someone stated:
<birdObservation1> rdf:type dwc:HumanObservation.
I think that would entail:
<birdObservation1> rdf:type dwc:Event.
because of the semantics of rdfs:subClassOf
On the other hand, if we assert something like
dwc:HumanObservation skos:narrower dwc:Event.
that would NOT entail
<birdObservation1> rdf:type dwc:Event.
but instead would entail different stuff like:
dwc:Event skos:broader dwc:HumanObservation. dwc:HumanObservation skos:narrowerTransitive dwc:Event. etc.
None of these entailments are intrinsically good or bad. But if we make assertions like dwc:HumanObservation rdfs:subClassOf dwc:Event. or dwc:HumanObservation skos:narrower dwc:Event. we must be aware that a machine could reason the entailed relationships, and should only make those assertions if we want a machine to be able to do those kinds of reasoning. In other words, we should only make assertions with semantic implications to accomplish some purpose related to machine reasoning, and not just because it seems like it might be a good idea. If our purpose is just to make things more clear to a human, then providing a better human-readable definition would be a better way to accomplish that.
Steve
Richard Pyle wrote:
dwc:HumanObservation rdfs:subClassOf dwc:[Occurrence]
But what would I gain by doing that? What would it prevent me from doing?
I'm not technically savvy enough to answer that question from an implementation perspective; but from a DwC comprehension perspective, it moves us a step closer to mutual understanding of how to transform DwC content into a functional data model. We all kinda/sorta know that already, but as evidenced by the different perspectives of "HumanObservation as a subclass of Event" vs. "HumanObservation as a subclass of Occurrence" just now revealed & expressed, it probably wouldn't hurt to be more explicit about these sorts of things in DwC documentation.