Draft: draft-ietf-core-coral

Commentary: 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 2 ) , 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 "  " , 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 does n'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 have n'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 ca n'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 do n'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 do n't know why I did n'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 had n'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 does n'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 " 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 .
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.
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.
each edge is passed at least one time in total,
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.
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.
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.
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.
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.
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.
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.
To illustrate the handling options for literals, a link example of
RFC8288 is converted.