Change:
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.

Discussion:
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

B to C, passings can only be along edges that can be reached from B along the graph, until B is the end of a different passing. <del> The passings starts at the root node, defined as the URI from which the document is obtained. </del> <ins> The passings starts at the root node, usually defined as the URI from which the document is obtained. </ins> For better understanding, think of the structured information model as a sort of tree spanning from the root node, with the oddity that

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

Each URI is tagged with whether it is intended to be dereferenced or used as an identifier. <del> Equivalence of literals over CBOR packing could be revisited; literals could gain an identity from all their outgoing trees being identical.  (But that'd need an exception for Null literals).  It might help to explicitly limit these sub-trees. Alternatively, literals in the model could be replaced with this, and be disallowed in the subject position: Literals can have properties in addition to their literal (CBOR) value.  These properties are expressed in key-value pairs very similar to statements about the literal in that the keys are URIs, the values URIs or literals, and keys can occur multiple times. (In serializations like binary, they are expressed exactly the same).  However, unlike statements, these properties of the literal and (transitively) part of the literal's identity, and are always expressed completely in the structured information model. If this model is adopted, literals obtain their identity from being identical in value and all properties in an unordered comparison.  "null" values need to be excluded from literals, as they need to retain the instance-of-their-own semantics. </del> 1.1.4. This subsection illustrates the information model and serialization

1.1.4.1. <del> To illustrate the handling options for literals, a link example of RFC8288 is converted. </del> <ins> To illustrate properties of literals, a link example of RFC8288 is converted. </ins> (Note that even the conversion scheme hinted at above for RFC6690 link format makes no claims at being applicable to general purpose

that apply to the described resource independent of which link is currently being followed.) <del> In the currently described model, the extracted data would be: </del> <ins> The model this would be converted to is: </ins> <del> If the alternative literals-with-properties approach were chosen, the extraction would produce: </del> <ins> | Subject | Predicate | Object | |------+-------+-----+ | http://.../ | rel:previous | http://.../TheBook/chapter2 | | http://.../TheBook/chapter2 | linkformat:title | "letztes Kapitel" with xml:lang "de" | {: #fig-8288-data-properties title='Information model extracted from fig-8288-orig'} </ins> <del> In CBOR serialization, both would produce the same output: </del> <ins> In CBOR serialization, this produces: </ins> 1.1.5.