33 Matching Annotations
  1. Mar 2024
    1. selection in SQL.

      (expressed, e.g., using WHERE and FROM clauses)

    2. should

      will

    3. n retrieved.

      comment on how the JSON has changed structurally? "list of attributes" became "dictionary of specific attributes".

    4. Exercise

      this exercise might be a bit too trivial?

    1. Only the first one will be successfully executed.

      would be instructional to also include the error messages of the others!

    2. Lesson 7.1 (coming soon).

      an earlier reference to Lesson 8 did not have the "(coming soon)" ... should it be everywhere?

    1. TypeQL is flexible enough that we could certainly do so if we wanted, but it is not particularly useful to and there are certain practical considerations that make the syntax tricky to use correctly. While learning the basics of TypeQL, it is best to avoid relates statements of this kind.

      instead of saying it's dangerous, can you saying something more concrete? (and less dramatic sounding :-D )

    2. Everything has a type, and so everything can be a variable.

      attribute to

      TypeDB Fundamentals, "Type Theoretic Foundations"

    1. If you see this result, you’ve set up everything correctly and are ready to begin learning how to read data in Lesson 3.

      I think it would be super useful to explain "Running a code selection" as well on this page (with screenshots). Otherwise, they'll have create a new file for each query.

    2. ff, open a

      reversed order of icon + button name?

    1. Inferred data is only generated once, so results returned are never redundant.

      unclear without further explanation

    2. Rule inference functions on deductive reasoning,

      unclear without further explanation

    3. resolved

      activated?

    4. locating

      AHHHHHHHHH

      it doesn't read good haha. what did we have against localization again?

    1. Parametric polymorphism

      prob rewrite intro paragraph. see individual comments.

      I'd rewrite this section which a focus on parametric statements. then "parametric query" can be a derived notation.

      Examples of parametric statements: $x sub relation; $y has $a; $b ($a) isa $T;

    2. The defining feature of parametric statements is that they do not include any type names, except for the root type keywords entity, relation, and attribute

      i would change this definition (I'm sure this won't impact the rest too much): the defining property is that they contain type variables that can potentially range over multiple inheritance hierarchies or interface implementations. Really, the feature to communicate is that we can have type variables! Of course, this is often implicitly, for example, match $x isa book; book owns $T; $a isa $T; $x has $a; could be match $x isa book, has $a; I'd rewrite this section which a focus on parametric statements. tbd

    3. While these queries are purely parametric, it is also possible to write non-parametric queries that include parametric statements, as we will see shortly.

      this should be the default definition.

    4. is particularly useful for parametric queries, but

      omit

    5. Parametric queries do not represent questions in the business domain, and are typically used to perform administrative procedures or database analytics.

      this should come a bit later? after the examples?

    6. Parametric queries are unique in that they are valid over any schema.

      not true since queries can parametric in some type but not another. i see no need to interpret "parametric queries" this strictly.

    7. hey match particular data by structure rather than by semantics.

      sentence probably too vague/philosophical to be meaningful to the average user.

    8. in the schema that

      are you saying somewhere that we will leave the schema implicit for now? otherwise the user may wonder where "the schema" is that you are referring to.

      (also structurally ambiguous usage of "that")

    9. locating

      still wavering on refactoring this to sth that reads better.

    10. type of ISBN we are providing.

      this could be: isbn13, isbn10, ....

    11. querying their supertypes, as

      i feel like the following is missing: subtype of a supertype is more special that then the supertype, conversely, a supertype is the generalization of (maybe many) subtypes.

    12. all three of these types are subtypes of book, which was the type we specified for $book

      where was this subtyping defined?

    13. Polymorphism in TypeDB

      each of the definitions below could do with a tiny bit more meat. Maybe 2 sentences per definition.

    14. type hierarchies

      still no mention of sub and supertypes?

    15. Allows us to define interfaces that can be implemented independently in the schema and then query those interfaces declaratively.

      a bit too vague. what are interfaces?

    16. m. In the following query, we adjust the previous query to retrieve the titles and page counts of all books.

      Explain the relation of book with the other types, don't to say "supertype" but sth is needed.

    1. match fetch attribute isa has entity relation isa! sub sub! owns relates plays

      make this comma separated