data with value/state lists are the norm, I agree with Daniel that we don't need restrictions. Strict restriction in the sense of "allowed value lists/enumerations" are difficult to manage in the face of massive collaboration and diversity of content. The classical 1980 solution is to enhance the definition state enumerations (= categorical values) while entering data. This works well in very small collaborations, but does not scale well to large collaborations. While not requiring restriction constraints in a classical sense, for descriptive data we would need some "constraint management". The management allows saving constraint violating values, while supporting review and revision of these. In my case, lists of _recommended_ categorical values even more that ranges or regexpressions. Below I describe one possible version of functionality specs. I know that this can not be realized now, but in the light of Jeroen's question is might be valuable to already now have such a future functionality in mind when setting up the data management. 1. For each property of type URL or string literal, a list of recommend values (a "recommended-rdfs:range") can be defined. These values must be supported in the sense that in addition to a code word a brief description/definition can be given. It may be best to only allow only items as values (which have a label and description). 2. Optionally, at a later stage, a second list of "accepted values" can be defined for each property 3. Items violating range or enumeration constraints for a given property can be imported and saved. 4. It is easy, by a standard mechanism, to analyze for a given property which items and which values are from the list of recommended values or the list of accepted values, and which not. 5. In the user interface of the editor, the user is supported by a display of recommended values. ---- Gregor