Change:
State a formal information model, and distinguish between the sea-of-triple-ish and the ordered-and-treeified structured data. I'll need to do some more polishing, but this is the rough form of what I'd like to try the various applications out with.
Thanks for the comments, and even more for sending them quickly. There are several stages of normalization; what I'd like to highlight here is that of the 4 steps on the comparison ladder (RFC3986 Section ), precisely this particular step should be taken. This might easily be said better somewhere else, and hopefully CRIs will turn out in a way that they are always in syntax based form, and thus the practical comparison is for identity. It is, but treating them by value is not. The canonocal example is two resources being labelled "Gift", but one is { "Gift" :lang :en } meaning present, and one { "Gift" :lang :de } meaning "present. It definitely needs much better phrasing -- or do you think the mechanism should be different too? What I meant writing this down is that if you have a bag of things and want to turn them into a mathematical (should have stressed that) set, there needs to be an equivalence relation that deduplicates items in the set. Same for the (mathematical) graph: items need identity to wind up as the identical node. I've written much of this in mental "math mode" (and it doesn't help that all the courses I did on basic maths were in German, so there might be translation errors too); in final ID form, this wil need different language. I've understood many practical concerns to necessitate a sequence on the items -- if the application should try items in a sequence, that sequence needs to be part of the information model at some point. There is no generic criterion, the ordering is just part of the additional information that the structured model carries and the general does not; clarified "structure (including the order)" below. "oriented" is a word I missed, making it explicit ("ordered oriented tree"). Yes, taken in. Is this a question in "why would you do that" (belonging to the rationale) or "what kind of tree allows that" (which means that I may need to pick a better word than the "ordered oriented tree" and have to resist the urge to hardcode it in even more unreadable set definitions)? (also see next comment). That's what you get from the odd tree above -- each time a node is entered, a different choice of picking a subtree can be made. That's what we get from expressing the tree acr^Wover the graph as a CBOR tree that may visit a node multiple times. If, of course, we choose to take the serialization avenue where such things are forbidden (and a multiply visited node must always come from the dictionary), then all the worries of these multi-ish trees go away. I'm very open to exploring that, it's just that AFAIR we haven't been there yet; all the proposals I remember on how to treat multiply visited nodes always had some optionality to using them. Taken in. What I'm trying to say is that if the serialization somehow manages to use the identical CBOR object again, it could easily manage to express that. The current serialization format can't do that (noted in the text for the time being), but if (for example) we were to cherry-pick the web linking feature of using multiple rel values in the same link, then a serializer could express a literal with multiple ingress edges, provided they all come from the same node and the serializer groups them together so that in the end the CBOR object is only in the document once. We'll find one in time. (This is so WIP that I don't expect much of the line-by-line text to make it to an uploaded ID, trying to hammer out the concepts first and slowly gathering phrases). That necessitated making "blank node" a term of CoRAL, but the change set in which I'm applying this contains such a change now.
Sorry for replying so late, I just realised this mega reply existed -- I don't know why I didn't receive an email notification from Github :-( I have to say bundling all comments and replies together makes replying a pretty hard task though. Maybe it'd be easier to use the threading that comes for free in the UI -- i.e., on each individual comments. Ah OK, I hadn't realised syntax-based is what you were aiming at here. Maybe s/syntax/syntax-based/ and a ref to the right place in the URI spec would dissolve any potential confusion.
Sorry for that -- they arrived at my mailbox in that format, and only later I realized that in the GitHub GUI they show as different threads. Good point, taken for update.
Action items for me before merging this: The term I've been looking for was probably DAG with ordering of the edges. [edit: it's not, because that doesn't encode when we go down which branch] (It may make sense to mention somewhere in there the possibility that subsets of statements and ontologies limit expresitivity to the point where there can only be one tree through the graph). Example of both versions of literals [edit: "Gift" -(lang)-> "de", -(direction)-> LTR vs. "Gift"NAME in the information model] with RDF mapping (with CBOR w/ cri"" extension as diagnostic format). Spell out dictionary mapping CBOR back and forth to XSD? (Might be moved to different issue that rebuilds RDF mapping based on this) Maybe point out things varying in serialization that are not even part of the structured thing (but still may be profiled), like absolute vs relative URs
As a result of , a mismatch in terminology remained: While the information model talks of a "root node", the Document Semantics section still talks of retrieval contexts; these are the same thing, and wording needs to be aligned. (This is especially relevant when converting with RDF; see upcoming commit in ).
Thanks! I've left a few comments.

Discussion:
1.1. <del> The data model derives from the Web Linking model of RFC8288 and consists primarily of two elements: "links" that describe the relationship between two resources and the type of that relationship; and "forms" that describe a possible operation on a resource and the type of that operation. The data model can additionally make simple statements about resources in a way similar to the W3C.REC-rdf11-concepts-20140225. In contrast to RDF, however, the focus of CoRAL is not on the description of a graph of resources, but on the discovery of possible future application states. </del> <ins> 1.1.1. The 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 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. 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 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. The is a sequence of "passings" the basic model's edges, where each edge is passed at least one time in total, each edge is passed at most one time after each passing that ends in its start point (with the obvious exception that edges from the root node can be passed once from the start), and between a passing of an edge from A to B and a later passing from 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. The passings starts at the root node, defined as the URI from which the document is obtained. For better understanding, think of the structured information model as a sort of tree spanning from the root node, with the oddity that when a node is reached along two different edges (which a normal tree doesn't do), it is up to the builder of the tree whether to describe anything children of the entered node on one parent or on the other parent, on both, or to describe some children at the first and others at a later occasion. 1.1.2. The structured form of a data set is in general not unique: If a node has more than one child, their sequence can be varied.  If a node has more than one parent, its children may be expressed on any non-empty set of its parents to obtain a structured data set that expresses the same data set. In general, arbitrary basic data can not be expressed in a structured data set, because There may not be a tree that covers the directed graph, or the tree's root may not be the URI from which the document is obtained. 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). In particular, the precise data from one structured information document can only be expressed at the same URI.  However, statements can be added to make a data set that is expressible elsewhere, 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. Forms are not special in the information model, but are merely statements around a blank node.  They can be special in serialization formats (which have more efficient notations for them), and are used by the interaction model for special operations. The structured information model contains more information than the basic information model.  [ TBD put this into a different context because it's not an observation any more: ] Which precise structure is picked is to suit the processing application, typically by profiling the information and its serialization.  It is recommended that the information encoded in the structure (including the order) be derived from data available in the general data set, even though the statements that guide the structure are not necessarily encoded in the subset of data that is being structured. Serializations like the one in binary have even more choices than the structured information model: They can choose to use or not use packed CBOR to compress parts, can spell out URIs in full or use relative references, or can exercise freedoms of the CBOR encoding. Variation there is not to have an influence on the interpretation of a CoRAL document. 1.1.3. Each URI is tagged with whether it is intended to be dereferenced or used as an identifier. 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. 1.1.4. This subsection illustrates the information model and serialization based on an example from RFC6690: After an extraction (currently not defined in this document), this list represents the content of the basic information model representing the above.  For the basic model, the table is to be considered unsorted in the first step. During extraction, some information on item ordering was preserved into the structured data.  Note that while the CoRAL structured data preserves some sequence aspects of the Link-Format file (like the order of attributes), others (like the relative order of links from different contexts) are deemed irrelevant and not preserved. For serialization, a (so far unspecified) packing was picked, resulting in a binary CBOR file with this CBOR diagnostic notation: Note that the "temperature-c" interface and "sensor" resource type get code points in the link-format dictionary because they are of reg-name style and thus would be registered as CoRE Parameters, and be included in the packing as well. 1.1.4.1. To illustrate the handling options for literals, a link example of RFC8288 is converted. (Note that even the conversion scheme hinted at above for RFC6690 link format makes no claims at being applicable to general purpose web links like the below; this is merely done to demonstrate how literals can be handled.  The example even so happens well illustrate that point: General link attributes may only be valid on the target when the link is followed in that direction ("letztes Kapitel" means last chapter), whereas convertible link-format documents use titles that apply to the described resource independent of which link is currently being followed.) In the currently described model, the extracted data would be: If the alternative literals-with-properties approach were chosen, the extraction would produce: In CBOR serialization, both would produce the same output: 1.1.5. </ins> The interaction model derives from the processing model of W3C.REC- html52-20171214 and specifies how an automated software agent can