Frequently Asked Questions
This page is an expanding set of FAQs about using schema.org terms in RDF.
1. RDFS and OWL Modeling of schema.rdfs.org
Q: Why do you limit the ranges of many properties to string? People might want to use URIs or blank nodes.
The RDFS translation only reflects what schema.org says. The expected type of many properties is “Text”, which we translate as string. We tried to formally describe schema.org in RDFS. We did not try to make a fork that improves upon their modelling. That might be a worthwhile project too, but a different project.
Q: Schema.org documentation explicitly say that you can use a text instead of a Thing/Person/other type, why is this not reflected in the RDFS?
That's ok—we didn't say that
schema:Thing is disjoint from literals, so you can use a string when the declared range is
schema:Person. (We were tempted to add “
xsd:string rdfs:subClassOf schema:Thing.” to capture this bit of the schema.org documentation, but narrowly decided against it.)
Q: Why don't you use
rdfs:Literal instead of
xsd:string to allow the strings to be language-tagged?
The problem is that
xsd:string is too narrow and
rdfs:Literal is too broad. We're waiting for RDF 1.1 to define a class of all string literals (tagged and untagged), and just leave the inaccurate
xsd:string in place for now.
Q: Why don't you use
owl:allValuesFrom instead of the ugly union domains/ranges?
This is a valid question in terms of good OWL modelling. But the current modelling is not wrong, and it's nicer to use the same construct for single- and multi-type domains and ranges.
Q: Nothing is gained from the range assertions. Why do you have them at all?
They capture a part of the schema.org documentation: the “expected type” of each property. That part of the documentation would be lost.
Q: Why don't you declare the single-valued properties as
The schema.org documentation unfortunately doesn't make it easy to determine which properties are single-valued. Using heuristics, such as looking for properties ending in “-s”, seems a bit risky.
2. The choice of URIs for schema.rdfs.org
Q: Why did you not mint new URIs, like
http://schema.rdfs.org/Thing instead of
Schema.org defines URIs for a set of useful vocabulary terms. The nice thing about it is that the URIs have Google backing. The Google backing would be lost by forking with a different set of URIs.
Q: The schema.org URIs don't resolve to RDF. Wouldn't it be better to mint new ones and make them dereferenceable?
Dereferenceability is only a means to an end: establishing identifiers that are widely understood as denoting a particular thing. Let's acknowledge reality: Google-backed URIs with HTML-only documentation achieve this better than researcher-backed URIs which follow all best practices.
Q: You say that
http://schema.org/Thing is a class, while it clearly is an information resource. Why are you violating httpRange-14?
Schema.org documentation uses these URIs as classes and properties in their RDFa example. They also return 200 from those URIs. So it's them who are violating httpRange-14, not us. We don't think they care much.
Q: Why don't you avoid the httpRange-14 violation by using URIs such as
Schema.org is using
http://schema.org/Thing as a class in their RDFa documentation. We don't want to mint different URIs in their namespace.
Q: Schema.org is about annotating web pages, so
http://schema.org/Person is not the class of people, but the class of web pages that are about people.
We think that
http://schema.org/Person is the class of people (and as such equivalent to
foaf:Person). It's just that the schema.org designers don't care much about the distinction between a web page and the topic of a web page.
Last Updated: 12 June 2011