-1 Had to deal with this in the frontend as well and don't think this is inconvenient. It seems like the cleanest approach. Polluting the Snaks with information like this for performance or convenience reasons will probably cause more trouble in the end than keeping it as simple and "pure" as possible.
2013/6/12 Daniel Kinzler daniel.kinzler@wikimedia.de
Hi all.
Currently, a PropertyValueSnak knows the ID of the property it refers to, and the DataValue object representing the actual value. The DataValue has a "low level type" used (in the future) by the storage and indexing layer. But whenever we want to render or validate a snak, we need the property's high level data type.
Currently, we do this via the PropertyDataTypeLookup service.
I think that's quite inconvenient and inefficient. I think the Snak itself should know the data type's ID. Was there any particular reason not to do this? I remember a lengthy discussion about this, but I don't recall the outcome (yes, we really need to write this stuff down).
Having the data type in the Snak would mean that Snaks are self-contained in the JSON structure, and it would also make us robust against a property changing it's type.
Of course, changing this now means we have to provide some kind of fallback for the case that the type id is missing - and that is going to require a PropertyDataTypeLookup again. Annoying :/
Alternatively, Snak objects could require the type in the constructor - but that would require database lookups during deserialization; not fun.
Any thoughts on this? Why did we go this route? And is it really too late to change this now?
-- daniel
Wikidata-tech mailing list Wikidata-tech@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-tech