Am 15.06.2013 01:17, schrieb Daniel Werner: > How would you use that additional type information?
For rendering the value, mainly. It seems awkward that I would have to look up the property's data type in order to render a value associated with that property. Who sais that values can not exist without being associated with a property? To me it seems natural that the data structure representing the value should be self-contained - that includes that it knows it's type. That way, the data structure contains all information necessary for interpreting it. > A PropertyValueSnaks (PVS) referencing a certain property can still have ANY > value of ANY value types, e.g. a value not necessarily matching the property's > data type's data value type. This is something all code should consider and > handle well. Code that assigns a new value to a given property, that is, code that creates or updates a snak value, needs to make sure that the value has the correct type for the given property. We currently already do this for the DataValue-type. All other code handling the value would just look at the value's data type, and not care about the property or it's type. > If you want to put the PVS's property's data type ID into the PVS instance, > then > what would that data type ID be? What would be the precise definition of that > additional field? It would be a data type identifier given as a string in the PVS's data structure. > * Would you take the ID of the PVS's property's current data type? > --> you still had to load the properties then when building the Snaks. Just > moving that inconvenience somewhere else. Yes, that wouldn't give us much, except for cleaner code for handling snak values. > * Or would you save that ID as part of the data model within the Snak already? > In that case the ID would refer to the PVS's property's data type at the time > of > the Snak's construction. Indeed. It would refer to the values *actual* data type, allowing us to interpret it correctly (especially for output, in the UI, in dumps, etc) even if the property's type changes. Currently, a property's type can never change - if it changed, we would lose the ability to interpret values that are already in the database. > - 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. > - The data type's structure could have changed (e.g. using a different data > value type). So even though your PVS is still referring to the same data type > as > the PVS's property, the PVS's value might not be valid against that data type > anymore. Something you still had to consider and check for. That is no different from the current situation. The code for creating value objcts (Snaks, DataValues) from array structures must be backwards compatible in any case, otherwise we lose access to existing values in the database. > --> all your type ID field would really stand for, would be "The data type the > PVS's value has been valid against at the time of its construction". At what > point is this information really useful? In how many cases can this really > spare > you loading the PVS's property to look up the actual data type? In all cases except when setting the value. > 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*. The point of having the value be self-contained and know it's type is to be able to *interpret* it safely without contextual knowledge. That would be far more robust than the current situation. -- daniel _______________________________________________ Wikidata-tech mailing list Wikidata-tech@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
