Change:
tree's root may not be the URI from which the document is obtained. <del> There may be multiple edges into a literal, and the serialization can not build a file where these are expressed at the same spot (which the current serialization can not do at all). </del> <ins> There may be multiple edges into a blank node. </ins> In particular, the precise data from one structured information <del> document can only be expressed at the same URI.  However, statements can be added to make a data set that is expressible elsewhere (this document defines the "carries-information-about" relation type leading to the "http://www.iana.org/assignments/relation/carries- information-about" predicate being usable here), and subsets of the data can be taken and expressed. Null literals are not special compared to other literals - they just happen to work like RDF blank nodes, and are also called blank nodes. </del> <ins> document can only be expressed with the same root node.  However, statements can be added to make a data set that is expressible elsewhere (this document defines the "carries-information-about" relation type leading to the "http://www.iana.org/assignments/relation/carries-information-about" predicate being usable here), and subsets of the data can be taken and expressed. Literals with properties behave similar to blank nodes (where their properties resemble statements from a blank node) - so similar that they are serialized precisely like that.  The difference is that properties are part of the literal's identity.  The structured model does not add structure to properties. </ins> Forms are not special in the information model, but are merely statements around a blank node.  They can be special in serialization

Discussion:
Closes: URL In the comments there's the question of whether we need that properties of literals that are literals themselves can have properties again. Right now it does no harm, but no good either; I have no use case that's not completely contrived, and the number of properties we can round-trip through RDF is quite limited anyway.
I think we should pick the information model variation where literals can't have arbitrary outgoing statements, but only properties (that happen to be serialized just like other statements). Allowing nested statements from literals is kinda nice conceptually, but it is hard to explain (as it requires all the "blank node" explanations over again) is impractical in conversions is hard to visualize correctly Realistically, literals can have a type (if they're string-form; for everything else conversion can be guided by tags) or a language (which AIU is also a type these days when considering LTR/RTL). We might also see things like content format (for embedded representations), but if we want to carry them over to RDF, we can't do the literal attributes anyway, and I think we don't need to (because we now also have 's tags for content formats and can thus easily tag things inside CBOR). Are there any arguments we should have in an issue beforehand? Otherwise I'd start a pull request at my next CoRAL session.
While writing this up, I stumbled over which CBOR data model to pick for equivalence. Making literals identical to each other if they are identical in the CBOR generic data model seems the right thing to do (as opposed to going into the extended data model), as it is easier and stable. I think that we (or applications) can still define additional equivalences later on.