fraunhoferfokus / rdfrulestreams Goto Github PK

Consider the possibility that the requirement for the order of version in the repositories of stores be in harmony with the order of the store could be dropped. If it is not required, then the order in the store versions would be take precedent. In this way you could impose a different order on a repository, e.g. as a different perspective on it, without having to create a new repository.

i find a description for revise and examples, but no definition.
neither in 3.4.1 nor in 5.5.

Tabulations of the query results of an "identity" query of a repository or store should help illustrate the structures.

include in the text

The application of Revise to this graph store with an OpInsertData operation specification as a lambda expression is expressed as follows.

some indication of the ground pattern "P".

the terms Assoc_k, Associative_k, and associative confuse as it is not clear which are functions, which are types.

TypeAssoc is already done

there was a passage where "Ext-DEFAULT" was wrapped as "Ext-DE- FAULT".
if the definition terms has classes, perhaps a global css definition is possible.
if not

<span style="white-space: nowrap;”> ... </span>

is cumbersome, but will prevent the wrapping

add a table, either early on, as a warning, or in an appendix as a summary, to enumerate the reserved names and their purposes.

the description is in terms of "DSP", while discussion of "k-th Order RDF Associative Tree" uses "AT" and "k-th order associative RDF data structure" uses "ADST".

• add a copy of the “we make” sentence into the introduction
• move the table into an appendix like the other inventory tables

is the cons argument order reversed?

VI = versionNames(R) and VI' = Cons(VI, name),

add a list of operators, as a table : names, signature, result type.

table 8. "metavariable conventions"has one line for each metavariable to indicate its type.

add a links from each variable to the point in the text of its first substantial use or definition.

add a description of the "DEFAULT", "ASSOC" and "REPO" notation.

... define a basic operation Append2Repository, [to do what …], as follows …

in general, as i contemplate operator implementation, many definitions are difficult to follow.
it would be helpful to have an initial discursive definition prior to the algebra and semantics, to say what the operator does to what.
if this explains what the arguments are and what is to happen to/with them, the definition is easier to follow.
in the pull request i did this to the dataset-union operator description.
an other example of better exposition would be that for Append2Store.

• in general some function names are capitalized and some are all lower. why?

• would "chain" be acceptable to name this operator? that would have the benefit that the argument order is not confusing. i note you indicate a different use for the operator later in the text.

the examples would be easier to read if you allow a shared prefix prologue and use prefixed datatypes. they might even be compact enough to fit into a two-column table rather than needing tagged paragraphs.

stay with "is undefined" phrasing

Application of a Revise operation to a structure without a terminal version is an error.

->

The result of the application of a Revise operation to a structure without a terminal version is undefined.

• remove notes which are too speculative (eg the first one in 3.5)
• resolve those for which that is possible. eg. the second note under example 6
• move notes which say “to be clarified in the section…” to that section. eg. under 3.6.3

• what do the paired entries for ::< and ::? indicate

• solitary-associationk ∩ "association-tree" : should be "associative-tree" ?

• is "[2^RDF-Name, Total-Order(RDF-Name)]" the same as 2^RDF-Name+, that is, the power set of sequences?

in "[k, N, M]", is N always non-empty?
that is, is

[1, {}, {DEFAULT=> [0, {}, {DEFAULT => G} ] ]

a valid order one associative?

the description of Append2Store does better than others to introduce the operator's purpose and effect, but it is missing part of its definition

We define a basic operation StoreTransformation_k with domain and range being stores of order k or less [ to ... here it should say do what to what for what goal … ]

the initial passage for "eval" introduces extensions to eval to support queries over streams.
in a sense, this is the point of the document.
some of this discussion belongs at the outset, to introduce an overview of the model and some concise claim about how that model will support the eval extensions.

in the namedPart definition

namedPart(DS) = Associativeorder(DS)(names(DS), nameMap(DS)(names(DS)) ∪ {DEFAULT => {} })

which uses

S => M(S) = {n => M(n) | n ∈ S} denotes the restriction of a mapping M to a set S ⊆ dom(M).

?
the notation looks like the same as when the name map applies to a name.
if a subscript would be appropriate for the restriction is would communicate the distinction.

in

A named graph may be emulated as a first-order associative tree that is also a solitary association.
A k-th order solitary association tree is a k-th order associative tree that is also a solitary association.

switch the order and describe the named graph as a "first-order solitary association tree"?

is the intended term "solitary association tree" or "solitary associative tree"?

strike "or less"?

is a .. versioned data structure STR which associates a sequence of revisions of the store with revisions of its repositories.
it demonstrates the following properties:

uses both "VS" and "VDST" for a k-th order versioned data structure.
is there a distinction?

the constraint in the tree definition would be better motivated if sequences had already appeared.

should this be

If previousTo(DST, DST'; DSQ) is defined, then follows(DST, DST'; DSQ) is defined

in

Note that by the definition of OpInsertData in [SPARQL11-Update], any blank node appearing in P' that also appears in P must be renamed.

allow for variant blank node surfaces by qualifyinf 1.1 semantics as a special case.

solitary associative tree, without qualificatin

• without qualification
• solitary associative tree -> "solitary tree" ?

the definition has four clauses.
why not use just the first and last?
the two asymetrical cases should return the same result as the last clause.

in the note, re-phrase as

 it is itself its associative part

as the works better with the text which follows.

i would understand the "solitary" relation to necessarily pertain to the just the order "k" structure.
if this is true, the description could be expanded to say that components must be trees, but need not be solitary.
if i misconstrue, the text ought to indicate that the constraint applies to constituents.

i do not see what it would need to, but just to be sure...

in table 11. "summary of operator syntax", as well as others, numerous entries are still just placeholders for the respective signatures and definitions.
similar applies to 3.4 "operator table"
similar applies to 3.2, the existing types

(this is already changing. the issue is itself just a placeholder)

there should be some sort of "content" operator which yields the graph associated with the timestamp triple.

• "timestampContent"?

the latest version (2d236f1..2b98c3a) seems to have lost section numbers.

• is “A” always a sequence? not in the general case, but with respect to store operations ?
• in "WindowRe_p, q(STR, N, v0)” is "STR" the store or some component of the store?
• "WindowRel_p, q" expression does alot at once. it switches p/q order, adds an argument, changes metavariables to use v0 v/s a and introduces terms, such as “RV”. that makes it difficult to follow. if the terms correspond to aspects of store definitions, it would help to reiterate what they mean.
• i am not sure how to express it more effectively, but, for example, in order to follow "Let Window(STR, n, p, q, rv0) = StoreTransformationk”, i need to page back and forth to the definition of that operation.

every time i return to the document, where there are changes to the terminology - even allowing that it is more concise and improved, i keep hoping i will find a "3.3.0" and "3.4.0" which each provide an overview of the types in the respective passage with a discursive description of how they relate to each other.

the relation between "index", "indexMap" and

The sequence corresponds to a mapping from the version names to the contents of the versions

is not clear.

... represented by repositories that comprise the same content and differ in regard to version order, rather than version content.

perhaps even call out the consequences in terms of changed/unchanged components.
that is, that the ordering changes, but the content (the codomain of the map?) does not.

data strucutures with triples -> "structures"

Associative is already done.

Need to rename

• Seq
• Versioned
• Repository
• Store

references to the rdfstream document ar still "@@@"

The table of types needs some formatting so the first column doesn't wrap.