I don't see any sense to include full class hierarchy in path.
It proposed something like this:
<div itemscope itemtype="http://schema.org/Sculpture/" >
<span itemprop="awards"> some award </span>
...
</div>
the short form is transformed into type + property name:
<div itemscope itemtype="http://schema.org/Sculpture/" >
<span itemprop="http://schema.org/Sculpture/awards"> some award </span>
...
</div>
and then there is no problem to assign property owner type (using classical OOP resolving scheme, if the property isn't overriden in child class, let's look at the parent class).
If there are more than one type, then every conflicting property must present in its full name with class prefix to avoid ambiguity.
Or I didn't understand the question?
14.05.2012, 12:25, "Adrian Giurca" <giurca@tu-cottbus.de>:
so, just following my example [1] you propose using the following solution:

<div itemscope itemtype="http://schema.org/Sculpture/" >
<span itemprop="http://schema.org/CreativeWork/Sculpture/awards"> some award </span>
...
</div>

Then on a large subclassOf hierarchy one would have
http://schema.org/Class1/Class2/.../ClassN/awards
and this would require the user to have this knowledge when annotate.

Do I have the right understanding?

Regards,
-Adrian

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



On 5/14/2012 10:12 AM, wrote:
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:
http://schemas.freebaseapps.com/type?id=/award/award_winner
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
http://schema.org/CreativeWork.

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
properties

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

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.

cheers,

Dan

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

--

http://staff.yandex-team.ru/elderos

--
Egor