Am 25.11.2013 06:45, schrieb Daniel A. R. Werner:
> I can see two solutions to have this implemented:Eek.
> -A: Gadgets with hard coded property specific rules. Very Wikidata specific
I think the correct way to do this would be to allow Claims on Properties. That
> -B: A generic constraint definition system for properties. No Wikidata specific
> defined by the community.
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 think that parsing, validation and formatting should all be controlled by the
> 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.
backend. That improves consistency, avoids redundant code and I think the
performance hit would be acceptable.
This basically means making WikidataDataTypeBuilders work based on user defined
> -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.
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.
Wikidata-l mailing list