(Denny: you can consider this a reply to your question from last Friday)
SnakSerializer already has:
// TODO: we might want to include the data type of the
property here as
This was written nearly as year ago, some things have changed since then.
In particular, it is now clear people want this, while there was no real
interest in the question back then. Of at least equal importance is our
change in defining what a DataType is and how these should be used. It
started of as the enabler of having an SMWDataValue like interface, and now
has been reduced to being a set of validation rules on top of a (Wikibase)
DataValue. While in the former case there are many reasons not to have any
logical dependency from DataModel on DataType, there are no such concerns
with the later (and current) case. Given what we want a DataType to be
(something that still needs to be reflected in its actual PHP definition) I
think it makes more sense to have it inside DataModel then in its own
component as it is now. It can then be linked to (logically or physically)
from PropertySnak, or newly introduced containers, as we desire.
Putting DT ids in DVs remains problematic, for the same reasons as before.
Luckily there are better alternatives then this approach.
Thought needs to be put into how to best move DT into DataModel, and how to
best make use of it there. Before any concrete action is taken, we might
want to have a close look at ValueValidators as well. This component has
some open design issues, and will be introduced as a new dependency of DM
if we move DTs there. Both of these concerns deserve their own discussions
and are quite distinct from the current one (which is more about "what?"
Jeroen De Dauw
Don't panic. Don't be evil. ~=[,,_,,]:3