Am 17.06.2013 14:02, schrieb Daniel Werner: > I am in favor of always displaying existing values if possible, even if it is > not valid against the current definitions (property/datatype) anymore. > BUT, if the value is not valid against the definition anymore, in many > situations the display of the value should come with an additional information > about that.
I'd say in *some* situations, not most. Definitly when editing. For general display in the UI, one can argue one way or the other. For all machine readable output (API, linked data, dumps) this is not relevant. > Otherwise this can be very misleading. How exactly? > In the JS UI we are currently not displaying those values, we only display a > red > message telling the user there is something wrong with the value and the user > can change it into something valid or remove it. I think it would be sufficient to do these things when editing. The point is: the value *is* valid. The idea is that the propery just provides the info which type new values should have. Existing values always have their own type, and they are valid against that. > For displaying the value in a useful way though, you don't necessarily need > the > PVS's Property's data type. Just having the data value, taking its data type > and > using a standard formatter for that data value type would be sufficient I > believe. This is only the case if we have a 1:1 mapping of data types and dv types. For example, commonsMedia (and soon URLs) use "string" DVs; But being restricted to a plain string formatter would be somewhat annoying, right? > We could already do that in the JS frontend for broken values of most > of our data value types, just nobody had the time to take care of it. I'm trying to introduce a PropertyBadValueSnak for handling this in PHP. Jeroen suggested we should ask Markus for input on that. > > Also, we might add other attributes than "datatype" to properties at > some > point, > > some might influence validation (e.g. the unit of a number). Would you > then go > > ahead and add these information also to the PVS's constructor? > > No, because it is only relevant for validation, that is, when the value > *changes*. > > > Not sure you thought this through. The example I gave (unit of a number) would > already be something not only relevant for validation but also for how the > value > should be displayed. Unit and precision are part of the "Quantity" DV, so they would be available without looking at the property. As they should be. > So my question still stands. I guess there are many more > possibilities of Property attributes that would not only affect validation. > With > your approach, we would take this flexibility. That's what I've been afraid of > in the first place. An optimization that will cost us time and nerves later > on. I would argue that any such information needs to be part of either the DV or the Snak, precisely for the reason that it is vital for interpreting the value. Again: the idea is that values should be self-contained. -- daniel _______________________________________________ Wikidata-tech mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
