jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-core-coral

Commentary: Work in progress
CoRAL can be used to build both open world systems ("if something is
not said, it may or may not be true") and closed world systems ("if
something is not said, it is not true").
In constrained environments (and the web in general), partial
representations are often used for efficiency.  For example, a device
can query another for particular statements using a yet to be defined
FETCH version of CoRAL.  It is expected that some tools (e.g., server
or agent libraries) require the application to be tolerant of
unprocessed statements.  Furthermore, it can be easier to evolve
applications and their packing dictionaries if loss of statements
leads to graceful degradation.
Therefore, it is convenient to build applications on open world
assumptions.  Such applications can only use statements that add
possibilities, and none that limit interactions.  Any limitations
need to be encoded in statements the agent necesarily has to perform
an action in the first place, and can then be relaxed in additional
statements.
For example, an application built with open-world assumptions can not
create a form that allows feeding gremlins, and in an additional
statement (e.g., a form field) forbid after midnight.  Instead, the
application needs to describe a limited-feeding form, which can only
be used if any of the attached conditions is met; the condition
"before midnight" can then be expressed in an additional statement.
Draft: draft-ietf-core-coral

Commentary: The introduction of the graph / statement based data model caused duplication between sections and text . This moves things into a common structure and removes textual duplication , smoothing some ( but not all ) of the rough edges .
The data model is similar to the W3C.REC-rdf11-concepts-20140225
model, with provisions to enable form based interaction and to
express data from Web Linking (RFC8288) based models such as
RFC6690's Link Format.
A CoRAL document consists of a list of zero or more statements that
can express links or (in a composition of statements) forms.  CoRAL
serialization formats may contain additional elements for efficiency
or convenience, such as an embedded base URI that takes precedence
over the document's base URI, or to concisely represent compound
statements (e.g., to express forms).
Any statement "links" a resource with a second resource or literal,
and is thus also referred to as a link.
However, a link in CoRAL does not have target attributes.  Instead, a
link may have a list of zero or more nested elements.  These enable
both the description of resource metadata and the chaining of links,
which is done in RFC8288 by setting the anchor of one link to the
target of another.
In the basic information model, the form is identified with an
anonymous node.  The form context and operation type are the subject
and predicate of an incoming link, respectively; request method and
submission target of an outgoing link.  Form fields are additional
links from that form.
A form field type identifies the semantics of the form field.  Form
field types are denoted (like link relation types and operation
types) by a URI.
Form field values can be either a URI, a Boolean value, an integer
number, a floating-point number, a date/time instant, a byte string,
a text string, or null.  A null indicates the intentional absence of
any form field value.
A form field type identifies the semantics of the form field.  Form
field types are predicates and thus URIs.  Form field values are
URIs, blank nodes or literals.
The data structure of a document in the binary format is made up of
three kinds of elements: links, forms, and (as an extension to the
CoRAL data model) directives.  Directives provide a way to encode URI
references with a common base more efficiently.
The data structure of a document in the binary format is made up of
three kinds of elements: links, forms (as short hands for the
statements they are constructed of), and (as an extension to the
CoRAL data model) directives.  Directives provide a way to encode URI
references with a common base more efficiently.
Draft: draft-ietf-core-coral

Commentary: 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 .
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.
Blank nodes are unnamed entities.  Literals are CBOR objects.
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.
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 the other literal's value in the
CBOR generic data model.
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.
To illustrate properties of literals, a link example of RFC8288 is
converted.
To illustrate non-trivial literals, a link example of RFC8288 is
converted.
The link relation types <http://coreapps.org/base#language> and
<http://coreapps.org/base#direction> are defined in core-vocabulary.
Text strings can be associated with a RFC5646 and a base text
direction (right-to-left or left-to-right) by using CBOR tag 38.
Draft: draft-ietf-core-coral

Commentary: Closes : This builds on 
 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 ) .
The passings starts at the root node, usually 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.
For better understanding, think of the structured information model
as a sort of tree spanning from the retrieval context, 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.
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.
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.
There may not be a tree that covers the directed graph, or the
tree's root may not be the retrieval context.
In particular, the precise data from one structured information
document can only be expressed with the same retrieval context.
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.
Draft: draft-ietf-core-coral

Commentary: The requirement was probably a left - over from when CRIs where specified in here ; the current document has no use for the properties obtainable from this . Closes : 
 The current text says : I think this is a remnant from when CoRAL and CRI were a single document ; I do n't see any reason to prescribe this for CoRAL . Any objections to removing that ?
A document in the binary format is encoded in RFC8949.  The encoding
MUST satisfy the Core Deterministic Encoding Requirements specified
in RFC8949.
A document in the binary format is encoded in RFC8949.
Draft: draft-ietf-core-coral

Commentary: This replaces the previous mechanism of having bespoke dictionaries with Packed CBOR . Other places in the text still talk of " dictionaries " , but that 's not necessarily wrong , it 's a term even used occasionally in packed .
A document in the binary format MAY reference values from an external
dictionary.  This helps to reduce representation size and processing
cost.  Dictionary references can be used in place of link relation
types, link targets, operation types, submission targets, form field
types, and form field values.
A dictionary reference MUST NOT refer to a dictionary value that
would otherwise not be syntactically allowed in that position.  For
example, a dictionary reference in the position of a link relation
type cannot refer to a Boolean value; it can only refer to an IRI.
A document in the binary format MAY reference values from an external
dictionary using Packed CBOR I-D.ietf-cbor-packed.  This helps to
reduce representation size and processing cost.
Dictionary references can be used subject to [ yet to be defined ]
profiling.
Implementers should note that Packed CBOR is not designed to be
uncompressed, but to be used in a compressed form.  In particular,
constrained devices may operate without even knowing what a given
dictionary entry expands to (as long as they know its meaning) .
Draft: draft-ietf-core-coral

Commentary: 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 ) .
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.
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.
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.
After an extraction described in convert-6690, 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.