Jeni's Musings

This discussion sounds familiar from discussions about object-oriented design: When should I use primitive types, and when should I create a class that wraps the primitive type or an enumeration type?

The answer is that enumerations are usually a good idea, but all the plumbing for wrapping a primitive into another object just to be able to attach some interesting methods that return derived values is rarely worth the effort.

Back to RDF: With controlled vocabularies, it’s relatively easy for the party defining the schema to provide an exhaustive set of URIs for all the terms in the controlled vocabulary.

In your color example, there’s more work involved: Someone has to design, implement, deploy, and operate a service that allows resolution of all the URIs in this very large color URI space. A simple static file with a few dozen resources will no longer do.

And when that is the case, then it’s probably more cost-effective to just go with a literal.

Information about an entity that can be easily derived, should be derived by the client, and expressing it as linked data is a bit silly I think, like the divisor example you gave.

A hunch for which I don’t have a good justification, I’ll just put it out there: You mentioned the case where you want “dynamic” URI spaces where some part of the URI, such as a date or geographic coordinate, is used in some computation. This gives rise to a URI space containing an infinite number of URIs. I think those should only be URIs of documents. For example, let’s say you want a service that, based on latitude and longitude, gives you nearby places of interest. Don’t build the service like LinkedGeoData so that it has a URI for each point on the surface of the Earth. Build the service so that there is a document describing each point on the surface of the earth, containing descriptions of the nearby places (which are a finite set coming from some database).