Frequently Asked Questions

This page is an expanding set of FAQs about using terms in RDF.

  1. RDFS and OWL Modeling of
  2. The choice of URIs for

1. RDFS and OWL Modeling of

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 says. The expected type of many properties is “Text”, which we translate as string. We tried to formally describe 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: 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 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 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 owl:FunctionalProperty?

The 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

Q: Why did you not mint new URIs, like instead of 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 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 is a class, while it clearly is an information resource. Why are you violating httpRange-14? 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 is using as a class in their RDFa documentation. We don't want to mint different URIs in their namespace.

Q: is about annotating web pages, so is not the class of people, but the class of web pages that are about people.

We think that is the class of people (and as such equivalent to foaf:Person). It's just that the designers don't care much about the distinction between a web page and the topic of a web page.

Last Updated: 12 June 2011