Am 25.11.2013 06:45, schrieb Daniel A. R. Werner:
I can see two solutions to have this implemented:
-A: Gadgets with hard coded property specific rules. Very Wikidata specific
-B: A generic constraint definition system for
properties. No Wikidata specific
defined by the community.
I think the correct way to do this would be to allow Claims on Properties. That
would basically be a generic, machine readable version of the constraint
templates currently placed on the Property Talk pages.
The question is then how the software would know how to interpret the properties
used in these constraints. Could just be configurable URIs, mapping them to
ValueValidators - not pretty, but practical.
I would much rather prefer the second solution.
And there are two ways to have that as well:
Snak value gets sent to the backend for real, evaluating the value against the
constraints, eventually notifying the user with a message instead of sending the
value to the backend.
I think that parsing, validation and formatting should all be controlled by the
backend. That improves consistency, avoids redundant code and I think the
performance hit would be acceptable.
-B2: Having this integrated on backend level.
(B1 Could be considered a clean non-wikidata specific solution of solution A above)
I would prefer B2 since it would concern changes done directly via the API as
well. Either way, this would be quite some work to be implemented, so I don't
think we will see this any time soon.
This basically means making WikidataDataTypeBuilders work based on user defined
constraints (using claims on the Property entity).
I agree that this should not be done in the first iteration of Quantity support,
but we should discuss it and then decide whether we put it on the road map.