2013/6/16 Daniel Kinzler <[email protected]>

> > - The data type of the property could have changed (we don't support
> changing
> > that as far as I know but I'd always consider it). So you still had to
> fetch the
> > property to compare its current data type with the one of the snak.
>
> Why would I have to check that? I'm trying to interpret a value for output
> or
> such, why should I (need to) care about the property's type?
>
> Only when *setting* a value we need to do this check, and we already need
> to
> check the datavalue's type in that case anyway.
>

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. Otherwise this can be very misleading.
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.

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

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

Cheers,
Daniel

-- 
Daniel Werner
Software Engineer

Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin
Tel. (030) 219 158 26-0

http://wikimedia.de

Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/681/51985.
_______________________________________________
Wikidata-tech mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikidata-tech

Reply via email to