Re: Naming Schema properties (Was: On using qualified names for properties)

so, just following my example [1] <#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 
>> <mailto: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