Schema.org both defines and uses the predicates named domainIncludes and rangeIncludes to relate types to properties (i.e. <schema:name> <schema:domainIncludes> <schema:Person> and <schema:name> <schema:rangeIncludes> <schema:Text>).
However in RDF Schema 1.1's specification, the predicates domain and range are already defined (giving <schema:name> <rdfs:domain> <schema:Person> and <schema:name> <schema:range> <schema:Text>).
My question boils down to: are schema.org's domainIncludes and rangeIncludes predicates equivalent to the RDFS domain and range predicates?
And if so:
rdfs:label and rdfs:comment. Was this a stylistic choice? (Did they not like the names "domain" and "range"?)owl:equivalentProperty or an equivalent? Schema.org should be explicit when creating predicates that are already defined by accepted standards such as RDFS 1.1, especially given its mission is structuring and standardising the web.Otherwise remain a big fan of schema.org : )
Why does schema.org define them in the first place and not just use the predicates provided by the RDF standard?
Schema.org doesn't want you to do inferencing using certain properties. If I knew that
<schema:name> <rdfs:domain> <schema:Person>
then whenever I saw a <schema:name> defined for an object, I could infer that the object was of type <schema:Person>. Schema.org uses <schema:name> for lots of things so uses <schema:domainIncludes> to indicate how you could or should use it but doesn't lock it down.
Why is this relationship between the predicates not defined using owl:equivalentProperty or an equivalent?
This is a policy issue for schema.org! My guess is that, like many general purpose ontologies (e.g. Semantic Sensor Network vocab), they like to keep weak semantics to allow for flexibility of application over the kind of strictness you're talking about that you need for inference.