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
> solution.

Eek.

> -B: A generic constraint definition system for properties. No Wikidata specific
> JavaScript required but Wikidata specific rules on the properties would be
> 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.
<https://bugzilla.wikimedia.org/show_bug.cgi?id=49554>

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:
> -B1: Getting the JavaScript UI to read those property constraints before the
> 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.
<https://bugzilla.wikimedia.org/show_bug.cgi?id=49186>

> -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.

-- daniel

_______________________________________________
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l