Draft: draft-ietf-core-coral

Commentary: Closes : 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 ca n'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 ca n't do the literal attributes anyway , and I think we do n'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 .
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.
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.
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, 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.
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
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.
The passings starts at the root node, defined as the URI from which
the document is obtained.
The passings starts at the root node, usually defined as 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 (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.
There may be multiple edges into a blank node.
In particular, the precise data from one structured information
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.
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.
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.
To illustrate the handling options for literals, a link example of
RFC8288 is converted.
To illustrate properties of literals, a link example of RFC8288 is
converted.