Change:
With direction on its way into a tag (discussion pending -- will it be a dedicated one or inside 38), the only use case we had for properties on literals is gone. I think the whole model is better if we remove them -- anything that can be expressed with properties can also be expressed with tags, but the latter are well defined and understood whereas the former are not. (What does it mean if two properties are on a literal and both are defined but their interaction is not? Tags are clearer there). PR is incomplete, needs a few more alterations.

Discussion:
are limited to the syntax-based normalized form of RFC3986 Section 6.2.2. <del> 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. </del> <ins> Blank nodes are unnamed entities.  Literals are CBOR objects. </ins> These triples form a directed multigraph with the subject and object being source and destination, and the predicate a description on the

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.  A blank node is only equal to itself.  A literal is equal to a different <del> literal if its value is equal to another literal's value in the CBOR generic data model, and have the same set of properties. </del> <ins> literal if its value is equal to the other literal's value in the CBOR generic data model. </ins> Triples are equivalent to each other if their subject, predicate and object are pair-wise equivalent.

predicate being usable here), and subsets of the data can be taken and expressed. <del> 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. </del> 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

1.1.4.1. <del> To illustrate properties of literals, a link example of RFC8288 is </del> <ins> To illustrate non-trivial literals, a link example of RFC8288 is </ins> converted. (Note that even the conversion scheme hinted at above for RFC6690

5.5. Text strings can be associated with a RFC5646 and a base text <del> direction (right-to-left or left-to-right) by nesting links of types <http://coreapps.org/base#language> and <http://coreapps.org/ base#direction>, respectively: </del> <ins> direction (right-to-left or left-to-right) by using CBOR tag 38. </ins> <del> The link relation types <http://coreapps.org/base#language> and <http://coreapps.org/base#direction> are defined in core-vocabulary. </del> <ins> [ Maturity note: Whether direction will actually be expressed in an updated tag 38, how precisely that is done, or whether a new tag will be allocated for text with direction is currently still under discussion. ] </ins> 5.6.