If we think in terms of multiple itemtypes, AwardableEntity must not be parent of Person and CreativeWork, it's a bad OOP practice.
I like approach used in Freebase:
which is more common than schema.org one: if you have a property which cannot belong to a certain type, you create a new type containing this property and use type composition.
But schema.org seems to be much simpler, and the schema is mantained by a few people, that's why there will not be much property name conflicts, and they all can be resolved.
The only thing I do not understand is why do we need types, if they don't have their own semantic. But since rdfa and microdata require types, why not?
14.05.2012, 11:57, "Dan Brickley" <danbri@danbri.org>:

On 14 May 2012 09:40, Adrian Giurca <giurca@tu-cottbus.de> wrote:

šHello Dan and all,

šI think the Egor's post on naming Schema properties [1]š opens an
šinteresting discussion. Let me exemplify by considering property "awards"
šdefined both by classes http://schema.org/Person and

šThe RDF approach defines the domain of this property as the union of these
štwo classes therefore when the property is named by http://schema.org/awards
šthen we get:

š<http://schema.org/awards> rdfs:domain <http://schema.org/Person>.
š<http://schema.org/awards> rdfs:domain <http://schema.org/CreativeWork>.

This would imply that anything that has an 'awards' property is a
Person, and also, a CreativeWork.

What we say is softer; that there is some (often nameless) class of
things that can have an 'awards' property.

From http://schema.org/docs/datamodel.html
"We have a set of properties
each property may have one or more types as its domains. The property
may be used for instances of any of these types.
each property may have one or more types as its ranges. The value(s)
of the property should be instances of at least one of these types."

šHowever in an object oriented approach if property naming considers the
šclassš who introduced the property, e.g., http://schema.org/Person/awards
šand http://schema.org/CreativeWork/awards then we have two different

š<http://schema.org/Person/awards> rdfs:domain <http://schema.org/Person>.
š<http://schema.org/CreativeWork/awards> rdfs:domain

šMoreover, http://schema.org/CreativeWork/awards would be allowed to be used
šon any subclass of http://schema.org/CreativeWork/ as keeping with
šset-theoretic semantics of object orientation (class as a collection of all
šits instances).

Which would pull you towards treating an 'awards' on 'Sculpture' as a
different property to an awards on 'ScholarlyArticle', 'TVEpisode'
etc., multiplying entities rather generously.

If some property has a domain of http://schema.org/CreativeWork then
we might expect the property to appear on anything that was a
CreativeWork, including for example a ScholarlyArticle. But (as above)
schema:domain is weaker than rdfs:domain, in that it's more of a
gentle documentation hint than a strict rule. The idea is to avoid
over-populating the schema with vague classes like "AwardableEntity"
as a common superclass of CreativeWork and Person.



š[1] http://lists.w3.org/Archives/Public/public-vocabs/2012May/0031.html