On 14 May 2012 09:40, Adrian Giurca <email@example.com> wrote:šHello Dan and all,
šI think the Egor's post on naming Schema properties š 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.
"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>.
š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
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.