Change:
is similar to the W3C.REC-rdf11-concepts-20140225 information model: Data is expressed as an (unordered) set of triples (also called statements), consisting of a subject, a predicate and an object.  The <del> predicate is always a URI, and subject and object are each either a URI, or a concrete CBOR object (a literal).  All URIs here are limited to the syntax-based normalized form of RFC3986 Section 6.2.2. </del> <ins> predicate is always a URI, the subject is a URI or a blank node, and the object is either a URI, a blank node or a litreal.  All URIs here are limited to the syntax-based normalized form of RFC3986 Section 6.2.2. Blank nodes are unnamed entities.  Literals are non-null CBOR objects that may have a set of properties (e.g. a language tag) attached to them; properties have a (not necessarily unique) URI as their name and a URI or literal as their value. </ins> These triples form a directed multigraph with the subject and object being source and destination, and the predicate a description on the edge.  That graph is equivalent to the data. To form a set and a graph, we define an equivalence relation: URIs <del> are only equal to URIs and if they are identical byte-wise.  Literals carry an identity from their serialization format (think of it as the file and cursor position from which it was read - but if cbor-packed is involved it's more like the stack of cursors at parsing time), and are only equivalent to themselves.  Triples are equivalent to each other if their subject, predicate and object are pair-wise equivalent. </del> <ins> are only equal to URIs and if they are identical byte-wise.  A blank node is only equal to itself.  A literal is equal to a different literal if its value is equal to another literal's value in the CBOR generic data model, and have the same set of properties. Triples are equivalent to each other if their subject, predicate and object are pair-wise equivalent. </ins> The

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.