In my understanding both of them can be converted to serial schedules. (This helps with consistency by isolation property while also giving the performance boost by concurrency).
I'm unable to understand one of the lines in this text: http://infolab.stanford.edu/~ullman/dscb/vs-old.pdf
Intuitively, view-serializability considers all the connections between transactions T and U such that T writes a database element whose value U reads. The key difference between view and conflict serializability appears when a transaction T writes a value $A$ that no other transaction reads (because some other transaction later writes its own value for A). In that case, the $w_T(A)$ action can be placed in certain other positions of the schedule (where $A$ is likewise never read) that would not be permitted under the definition of conflict-serializability.
I understand that the circumstances that can cause inconsistencies (if transactions are swapped) and affect the conflict serializability are
write(Q) by T1 and then write(Q) by T2, or
read(Q) by T1 and then write(Q) by T2, or
write(Q) by T1 and read(Q) by T2.
It seems to me that some special cases are allowed as per
view serializability but I've not been able to pin point those cases. Any help is appreciated.