911 Matching Annotations
  1. Nov 2021
    1. A significant drawback is the overload of the named graph parameter with an identifier instead of the file or source that produced the triple.

      What does it mean?

    2. What RDF* Improves

      A shortcoming of RDF* is in inability to reference multiple triplets.

    3. Technically, this is a fourth element, which can be attached to the <subject, predicate, object> triple

      In case there are multiple graphs that intersect on the same triplets, there may be a lot of repeated triplets.

    1. In particular we intend to use content-addressed ActivityStreams over XMPP.

      Sounds interesting.

    2. difficulties in providing reproducible development environments

      ClojureScript has problems with rde?

    3. It requires the usage of algorithms (e.g. the Expansion Algorithm or the Framing Algorithm) that are incomprehensible and just pure madness.

      I am not familiar with how it works, but it appears to me to be a straightforward derivation both ways.

      I wonder where I might be wrong.

    1. while the result of the checkout is called a working directory

      Why not "repository"?

    2. Updating a working copy with the latest files from the repository is simply called update

      Why not "checkout"?

    1. test.txt v1

      This git object is a blob, it does not carry information that it is named "test.txt v1" under a tree. (Also, the same blob can be referenced from different trees, and it can have different names as well.)

    1. git-cat-file

      Why is it not called 'git-cat-object', since it works on objects?

      An "object" can represent not only a "file" ("blob", in git's terms) but a "directory" ("tree", in git's terms) as well.

    1. By operation of the pigeonhole principle, no lossless compression algorithm can efficiently compress all possible data.

      I don't get it.

    1. Composing knowledge from events In any multi-actor system, like a team of collaborating robots, every actor must make decisions based on some current knowledge: a local world model, or an evolving set of goals. It may not be possible to centralise that knowledge – for example if the actors can lose their network connection; or the latency or locking behaviour of a central database is not acceptable. If the contributing data events are frequent, for example from sensors, every update has to be synthesised by every actor into their knowledge. This can rapidly become a computational headache. m-ld can help. The knowledge itself is maintained as convergent shared state, and each actor only needs to apply their own updates. The rich query syntax then lets them act upon what they need to know, when they need to act.

      Actors make decisions based on their local perception of the world.

    1. Connections between users of a social network

      Connection of user A to user B may not be the same as connection of user B to user A.

    2. There is no single best way to structure one’s data; every choice comes with significant tradeoffs. The larger our dataset becomes, the more important it is to tailor its structure to the way we intend to use and access it.

      Why not create as many indexes/data-structures as there are use-cases?

      Since any piece of content can be referenced a file-system-like index can be as such:

      pics
      ├── 2018
      │   ├── 2018-02-23-tabby.png
      │   └── 2018-04-14-tropical.png
      ├── cats
      │   ├── 2018-02-23-tabby.png
      │   └── 2019-12-16-black.png
      └── fish
          ├── 2017-03-05-freshwater.png
          ├── 2018-04-14-tropical.png
          └── 2020-10-02-blowfish.png
      

      Although this data structure seem to serve too many use-cases, it can be split.

    3. and the functions or operations that can be applied to the data

      This is not responsibility of a data structure.

      A data structure structures data, nothing else.

    1. Annotation with a SpecificResource that has a Selector for each of the Body and the Target

      Selector can be used as a Body.

    2. Describe the style in which the source resource should be presented for the Annotation

      Preference of how to perceive content seems to be a matter of taste and use-case, making it imposible to satisfy all possible combinations with a provided way.

      Perhaps this should be left on responsibility of an end-user?

    3. or simply the location where the current harvesting system discovered the resource

      In case annotation copies are being accreated with reasoning it will be hard to connect such reasoning.

      E.i., reasoning on copy A would not know of reasoning on copy B.

      It seems that all reasoning should be performed on original.

      Perhaps, to achieve that copies could be made unannotatable?

    4. Other Identities

      This is another big problem that seems to be out of scope of the problem this spec is meant to solve.

    5. is NOT RECOMMENDED for uses where the Body may need to be referred to from outside of the Annotation

      I'd imagine if an Annotation is meant to stay on the web indefinite, as would be in the case of immutable web that we may get at some point, at some point in time there inevitably will be a third-party that would like to annotate that annotation.

      Annotations that do not support annotation in turn would prevent further reasoning.

      For the web that is an open platform that seems to not be fitting.

    6. Hannah associates a tag and a description with two images using a single annotation

      How, in this case, Hannah would refer to an image from within the description?

    7. Her client associates a stylesheet with the Annotation

      Why to capture a stylesheet instead of what she wanted to express, as semantic data?

    8. is NOT RECOMMENDED for uses where the Body may need to be referred to from outside of the Annotation

      That seems to be the case not only for "bodyValue", but for "body" of type Resource as well, as it is also is not referencable.

    9. The identity of the SpecificResource is separate from the descriptions of the constraints.

      Why?

      SpecificResource can be uniquely identified by a composite identity of URI of Resource + constrains.

      That would allow to escape the need to have another extraneous unique id registered.

      Also that would allow different parties to deterministically uniquely identify the same SpecificResource without any communication.

    10. fragments for HTML cannot be used to describe an arbitrary range of text

      How to do so?

    11. "type": "Video"

      Even if no "format" is specified in an Annotation it may be specified in an External Web Resource.

    12. "type": "Video"

      Some clients may support one specific type and not support another specific type.

      By supplying generic type with no specific type we may encounter a case when a client may not be able to tell based on a generic type whether it can handle data or not.

      E.g., a client may support video/mp4 and not support video/ogg, leaving it unable to predict whether it can handle data typed as "video".

      It seems to me that a scenario when a client is not able to handle all specific types of a generic type is rather common.

    13. 3.2.2 Classes

      Can a specific type be expressed via Classes?

    14. it is also useful for a client to know that a resource with the format text/csv should not simply be rendered as plain text

      It should be up to a client to decide how handle data.

    15. It is useful for clients to know the general type of a Web Resource in advance.

      Ain't a general type can be derived out of a specific one?

      E.g., it is possible to derive a generic type of a specific mime type, because mime types have structure of type/subtype.

      E.g., video/mp4 -> video

    16. if information provided by the external resource contradicts the information provided by the annotation about it, then the external resource is authoritative and the information from the annotation should be disregarded

      Annotation refer an exact value of a resource.

      Annotator most likely does not expect this value to change.

      However, resources cannot be enforced to be immutable.

      Allowing an annotator to provide such local parameters would allow them to rely on at least their immutability.

    17. if information provided by the external resource contradicts the information provided by the annotation about it, then the external resource is authoritative and the information from the annotation should be disregarded

      Ain't it up to Annotation to decide how to view a resource?

    18. if information provided by the external resource contradicts the information provided by the annotation about it, then the external resource is authoritative and the information from the annotation should be disregarded

      Why so?

    19. textDirection

      Ain't this property can be derived out of 'language' property?

    20. processingLanguage

      Why Annotation takes on responsibilities of presentation?

      It can be presented in a miriad of ways and it's up to the consumer to decide how to view it up to their preferences.

    21. This information may be recorded as part of the Annotation, even if the representation of the resource must be retrieved from the Web.

      This seems necessary, because an author of Annotation may be a third-party for Target or Body, having no control over it, and yet may want to specify some data about it.

    22. the Body may also be embedded within the Annotation

      It won't be possible to refernce such Body of a published Annotation.

      So it won't be possible to annotate such Annotation.

      I.e., it is not possible to use such Annotation for reasoning further on.

      That may be fine in case no third-party will ever want to annotate it / use as part of their reasoning, but personally I would not be comfortable to count on that.

      Based on that reasoning, it seems to me that for the open web it would be more suitable to require of any published Annotation to have a referencable Body.

    23. the Body may also be embedded within the Annotation

      What for?

    24. An Annotation is a Web Resource.

      Is it a must for an Annotation to be resolvable?

      I.e., can it be not a Web Resource, but a Resource?

    25. Class Resources may be divided, conceptually, into groups called "classes"; members of a class are known as Instances of the class. Resources are associated with a particular class through typing. Classes are identified by IRIs, i.e., they are also Web Resources themselves. Type A special Relationship that associates an Instance of a class to the Class it belongs to. Instance An element of a group of Resources represented by a particular Class.

      What is it for?

    26. representation of the Annotation

      What parts does representation of Annotation have?

    27. are not to be considered authoritative information

      Why so?

    28. collections

      What is a "collection"?

    29. The Body resource may be a choice between multiple resources.

      Why?

    30. The Target or Body resource may be included in the Annotation to play a specific role.

      Why?

    31. The Target or Body resource may be included in the Annotation to play a specific role.

      What are such roles?

    32. The Target or Body resource may be a specific state of the resource.

      Target may refer to an html Resource.

    33. The Target or Body resource may be a specific state of the resource.

      What 'states' are possible?

    34. The Target or Body resource may be styled in a specific way.

      Why to style?

    35. rooted

      How so?

    36. associations between resources

      How to express what annotation refers to?

    37. structured model and format

      What's the difference between "structured model" and "format"?

  2. Oct 2021
    1. it’s really annoying

      I see how comments can be annoying to one.

      They may annoy if they are not useful.

      And their usefulness depends on use-case (a shocker, I know).

    2. Comments can lead you astray, because they get out of date. The code is the only source of truth.

      This is a sign that reasoning is not being captured thoroughly.

    3. These shouldn’t be comments! They should be in commit messages, or the wiki, or the issue tracker, etc

      Why should reasoning be spreaded across these places?

      Anything created in a project is an artifact of human reasoning, be it a mindset expressed in a text chunk, organization expressed in issues, sprints, etc., or a code block.

      All of that is humans' reasoning, some informal - expressed in a natural language; some formal - tickets, mock-ups, code. But it's reasoning nonetheless and it can be expressed in one reasoning graph, from a non-formal idea in a natural language down to a formal implementation in code. If the semantics are captured as data (of a ticket, of a meeting event, etc.), then tools of one's choice can be used by him to work on that data.

    1. RDF is an abstract knowledge representation model that does not differentiate data from metadata.

      It seems to me it does.

      RDF allows to express nodes and edges that reference nodes. Edges are metadata.

      My reasoning is:

      • Edges are data about nodes.
      • Nodes are data.
      • Edges are data about data.
      • Metadata is data about data.
      • Edges are metadata.

      However, what RDF does not allow is for an edge to reference another edge.

      I.e., nodes are referencable, edges are not.

      I.e., RDF does not allow metadata about metadata.

      RDF* allows exactly that, unlocking meta-level depth.

    1. Nested Embedded Triples

      Opens up a meta-level play.

    2. What RDF* Improves

      In RDF there are nodes and edges.

      RDF* allows to treat edges as nodes.

    3. :hasSpouse is a symmetric relation so that it can be inferred in the opposite direction

      :hasSpouse is a 2-ary relation.

    4. the metadata in the opposite direction is not asserted automatically, so it needs to be added

      This is a denormalization.

    5. <<:man :hasSpouse :woman>>

      There may be more than one :man :hasSpouse :woman, how to specify the exact one? I.e., statement may not be unique.

    6. What RDF* Improves

      A feature of RDF* is that it allows to reference relationships without the need to reify them.

      That means no change to data-model is required to be introduced when one wants to reference to a statement.

    7. << <<:man :hasSpouse :woman>> :startDate "2020-02-11"^^xsd:date >>

      Neat.

    8. According to the formal semantics of RDF*, each embedded triple also asserts the referenced statement and its retraction – deletes it. Unfortunately, this requirement breaks the compatibility with the standard reification and causes a non-transparent behavior when dealing with triples stored in multiple named graphs. GraphDB implements the embedded triples by introducing a new additional RDF type next to IRI, blank node, and literal.

      So the same syntax (<< >>) is overloaded with a different behaviour in GraphDB?

    9. GraphDB implements the embedded triples by introducing a new additional RDF type next to IRI, blank node, and literal.

      Where the formal definition of this type can be found?

    10. According to the formal semantics of RDF*, each embedded triple also asserts the referenced statement and its retraction – deletes it.

      Where does it state so?

    1. RDF reification as demonstrated in the example has two major shortcomings

      Another shortcoming is that a reified statement is not reified by itself.

    1. Scalability: In a many-to-many system, scale is essentially unlimited. Hardware (nodes) can be added at ease in any home or office by anyone, which is not the case with the current data center model.

      Yet datacenters have more resource budget before they run out and they provide scale seamlessly.

    1. it is possible so make following a link fire up a special application

      How could it be implemented?

    2. One must also be able to annotate links

      Are there any developments on this?

    1. a user de-fined extension namespaces

      What is that?

    2. Each SPARQL implementation has its own protocol torealize the binding between extension namespaces and function definitions

      I don't get. An example?

    3. limits the interoperability of the query

      How so?

    4. query and search

      What's the difference between "query" and "search"?

    1. Given the restrictions of the sandboxed iframe, it is not able to make calls outside of its own frame, nor is it able to read or modify anything about the parent page.

      Very nice.

    1. they can perform I/O using XMLHttpRequest (although the responseXML and channel attributes are always null) or fetch (with no such restrictions).
      <anchor>
    1. It is an isolated environment that is insulated from the window object, the document object, direct internet access

      Is it so?

    1. more difficult to maintain

      How so?

    2. make our components larger

      Overhead of FRP engines baked into WCs may indeed add up to a substantial size by Web standards.

    3. convolute the code

      How so?

    1. Notes

      I'm curious to see how an example case of 30 ReactJS components with different ReactJS versions are going to look like. Having dependency on a different version of a library is the most likely scenario in practice. How will dependencies be managed in this case?

    2. All components will share the library code

      How does it work?

    1. Automatic linking of other resources and discussions

      What problem is it meant to solve?

    2. Portability across hosting services

      What is meant to be hosted?

    3. Rich connections to other online resources
    4. Discovery and linking of annotations across different content instances (html vs. pdf)
      <anchor>
    5. Rich

      What is meant by "rich"?

    6. Many different clients that support basic functionality

      Are there any implementations?

    7. Tags that help filter, sort, identify annotations by date, relevance, topic…factual annotations vs. comments  (pragmatic vs. true semantic interoperability)

      Perhaps RDF is a good fit for it.

    8. People identifiers within groups and globally (SSO including with ORCID), w/ Twitter, other SM groups

      Can this problem of identifying people be solved by WebID?

    9. repositories

      What is it?

    10. versions of content

      What is meant by it?

    11. Selection

      What is it?

    12. ability to evolve permissions on selected annotations

      How to control who's allowed to evolve?

    13. branded

      What is it?

    14. authoritative

      What is it?

    15. private group

      What is it?

    16. but

      Why "but"?