fix typos

_papers/thesis-report/chapters/evaluation.typ

@@ -86,7 +86,7 @@ In the worst-case scenario, all collections could save the resource, but they on
 In such a case, all resource descriptions pointed to by canonical collections need to be checked.
 
 The cost of a single validation can be linear in the number of properties the description has.
-Since the focus of the resource is on a single named node, only that named node should be seen as a focus node in the validation.
+Since the focus of the resource is on a single named node, only that named node should be considered as a focus node in the validation.
 
 The computational load could be reduced when multiple resource descriptions share have overlapping descriptions.
 A shape could in that case be defined as a conjunction using `sh:and`.
@@ -99,13 +99,13 @@ ex:PictureShape
 
 ex:WhatMakesPicturePersonalShape
   a sh:NodeShape .
- 
+
 ex:PersonalPictureShape
-	a sh:NodeShape ;
-	sh:and (
-		ex:pictureShape
-		ex:WhatMakesPicturePersonalShape
-	) .
+  a sh:NodeShape ;
+  sh:and (
+   ex:pictureShape
+   ex:WhatMakesPicturePersonalShape
+  ) .
 ```
 ]
 In this case, a query engine could cache the evaluation result of `ex:Picture`.
@@ -134,7 +134,7 @@ In the case of @uri templates with regexes, this cost negligible.
 The Solid Specification requires updates to happen using N3Patch,
 this means that each created resource requires its own @http request.
 
-Interestingly, some implementations of a solid server, like the 
+Interestingly, some implementations of a solid server, like the
 #link("https://communitysolidserver.github.io/CommunitySolidServer/7.x/usage/example-requests/#patch-modifying-resources")[Community Solid Server]
 also accept SPARQL queries.
 
@@ -161,7 +161,7 @@ INSERT {
 
 ==== Fetch the Description and the Resource
 
-Like with creating a resource, we need to fetch the @sgv, costing us one @http request. 
+Like with creating a resource, we need to fetch the @sgv, costing us one @http request.
 Additionally, we need to fetch the current state of the resource, costing us at least one additional @http request.
 Luckily, these requests can be done in parallel, minimizing delay.
 
@@ -193,7 +193,7 @@ two, non-parallel @http requests
 
 ==== Conclusion Resource Update, No Move
 
-We can conclude that the cost of an @rdf resource update is two in case of an update that only deletes or adds triples, and three in case of an update that does both deletes and updates.
+We can conclude that the cost of an @rdf resource update is two in the case of an update that only deletes or adds triples, and three in the case of an update that both deletes and updates.
 
 It should, however, be possible to do it using only two @http requests.
 
@@ -305,7 +305,7 @@ ex:PostShape {
 
 === Test Hardware Specification
 
-For completeness sake, We quickly describe the system used in the benchmarking.
+For completeness’s sake, we briefly describe the system used in the benchmarking.
 I am using a Dynabook Inc. Satallite Pro A50EC with 16 GiB memory, an Intel® Core™ i5-8250U x 8 processor and an Intel® Graphic UHD Graphics 620 (KBL GT2).
 The installed operating system is a Fedora Workstation 39 (64-bit), and firmware version 2.70.
 
@@ -320,7 +320,7 @@ The choke points we will be testing are:
 + *Delete resource*: @fig:delete-data-complete, @fig:delete-where-complete
 
 The queries should cover all different queries from the update @sparql spec (see @sec:sparql-query-types).
-Because we want to cover all type of queries, some choke points are represented by more then one query.
+Because we want to cover all types of queries, some choke points are represented by more than one query.
 
 
 #grid(
@@ -550,7 +550,7 @@ The ratios of @sgv[-]operations over non-@sgv[-]operations per second are:
 
 Altough these ratios are still better then the hypothezized $0.25$, they are significantly worse then the previous section.
 That's to be expected because the @sgv enabled equery engine has to perform more steps now.
-Eventough it is worse accross the board, we still see that the fragmentation strategy plays a roll. 
+Eventough it is worse accross the board, we still see that the fragmentation strategy plays a roll.
 
 #figure(
   insert-where-tag,
@@ -585,7 +585,7 @@ The @sgv engine requires multiple additional @http requests, that are not perfor
 The ratios of operations are: $#calc.round(6/35, digits: prec)$ ; $#calc.round(2/5, digits: prec)$ ; $#calc.round(5/35, digits: prec)$ ; and $#calc.round(6/35, digits: prec)$
 We can thus say this breaks our hypothesis.
 Again, we highlight the difference between fragmentation strategies.
-Clearly, the delay experienced from loading the large file in the case all posts are saved in the same file is significant. 
+Clearly, the delay experienced from loading the large file in the case all posts are saved in the same file is significant.
 
 #figure(
   delete-insert-id,

_papers/thesis-report/chapters/preface.typ

@@ -12,7 +12,7 @@ However, today's Web has become increasingly centralized,
 as most of the data is centralized in a few large data stores
 which are in full control of massive companies such as Amazon and Google.
 //
-This centralization of data on the Web leads to a number of problems,
+This centralization of data on the Web leads to numerous problems,
 such as privacy-related issues as *people are not in control of their own personal data*~@bib:verborgh_timbl_chapter_2023.
 
 To solve these problems caused by data centralization,
@@ -33,7 +33,7 @@ such as _BBC_ (UK), _Digita_ (Flanders) and _Inrupt_ (USA).
 The *fundamental shift* from centralized data management comes with various challenges.
 The solid community tries to tackle these challenges through a specification.
 Interestingly, a rather unexplored domain is that of writing data.
-In this thesis, I will explore how we can *abstract data updates*, with a focus on solid. 
+In this thesis, I will explore how we can *abstract data updates*, with a focus on solid.
 
 == Problem Statement
 
@@ -58,7 +58,7 @@ To relieve application developers from needing to write complex software to comm
 These query engines already allow developers to query pods efficiently.
 Through a technique called link traversal querying, a developer can give the root path of a solid pod and query the whole pod.
 Speed-ups can be gained by incorporation the structure of the pod in the query evaluation.
-This structure can be described through different vocabularies, examples include, Type Index, Shape Trees, @void, @tree and @ldes.
+This structure can be described through different vocabularies, examples include, Type Index, Shape Trees, @void, @tree, and @ldes.
 
 A pod can thus be structured, and since @ldp maps to a file system, everyone, from data consumer, data producer and data owner, benefit from a good structure.
 Unfortunately, as of currently, there are no automated clients that infer where to store a resource in a way that does not break the structure.
@@ -75,7 +75,7 @@ We quickly go over the different terms in that question.
 - Abstract data updates: We aim to abstract the query process, so a developer does not need to interact with the pods interface themselves.
 - Document oriented interface: the interface we interact with exposes data through @http resource in plain text.
 - Permissioned: each @http resource has access rights configured, rights can target specific actors or everyone.
-- Decentralized: each pod is self governed and limited rules apply to the system, a loosely defined systems data publisher to be opinionated. 
+- Decentralized: each pod is self governed and limited rules apply to the system, a loosely defined systems data publisher to be opinionated.
 - Query abstraction layer: we want the abstraction to happen through a declarative query. We will use the @sparql query language.
 
 == Hypotheses <sec:hypotheses>
@@ -88,4 +88,4 @@ For applications that do not write too often, this is an acceptable overhead for
 
 == Outline
 
-#todo[describe outline when we are done]
+#todo[describe outline when we are done]

_papers/thesis-report/chapters/semantic-web.typ

@@ -69,7 +69,7 @@ depending on the chosen character, your triple shares, respectively, the object,
 Blank nodes have some additional syntactic sugar and can be created using brackets ("`[]`") in which the predicate and object belonging to the blank node are contained.
 An additional feature is the use of a "base".
 Turtle allows you to specify named nodes (@uri[s]) in relation to a base by using the `<>` containing a path instead of a whole @uri.
-The base @uri should be provided when parsing the turtle file. 
+The base @uri should be provided when parsing the turtle file.
 @fig:example-turtle is a turtle serialization of @fig:example-n-triples when using the base @uri "http:\//base.example.com/".
 
 #figure(
@@ -99,7 +99,7 @@ ex:Bob
 
 == SPARQL <sec:sparql>
 
-The @sparql query language is a declarative query language like for example, SQL, but specifically designed for RDF. 
+The @sparql query language is a declarative query language like, for example, SQL, but specifically designed for RDF.
 The query language is very extensive, in this section we explain what is needed to understand this work.
 
 @sparql and turtle share a lot of syntax, with a minor nuance in prefix declaration. Turtle uses `@PREFIX` to define a prefix, while @sparql just uses `PREFIX`. Turtle also expects a dot at the end of a prefix declaration, while @sparql does not.
@@ -118,7 +118,7 @@ Binds a certain value, or variable, to a variable. To bind the value "apple" to
 
 ==== STR
 
-The STR function gets the raw string representation of a value, for example when we have a date: `"2024-05-08T23:23:56.83Z"^^xsd:dateTime` we can get the value between double quotation marks by using the STR function. `STR("2024-05-08T23:23:56.83Z"^^xsd:dateTime)` would evaluate to `"2024-05-08T23:23:56.83Z"`. 
+The STR function gets the raw string representation of a value, for example when we have a date: `"2024-05-08T23:23:56.83Z"^^xsd:dateTime` we can get the value between double quotation marks by using the STR function. `STR("2024-05-08T23:23:56.83Z"^^xsd:dateTime)` would evaluate to `"2024-05-08T23:23:56.83Z"`.
 
 === Property Paths
 
@@ -241,8 +241,8 @@ An @ldp interface allows CRUD operations through the @http methods. #todo[talk a
 
 Query engines are complex pieces of software that answer queries, like for example the @sparql queries seen in @sec:sparql.
 The features supported by the engine are engine-dependent, but they can be extensive.
-Besides feature support, they can also perform query optimizations based on things like cardinalities that are either known from the start, or are discovered during the query process. 
+Besides feature support, they can also perform query optimizations based on things like cardinalities that are either known from the start, or are discovered during the query process.
 A query engine aims to shield the developers from the complexities that are omnipresent when querying data.
 These complexities range from different data formats, to different interfaces, to possible optimizations.
 
-The Comunica query engine has been especially designed to be modular, allowing easy extensibility in the different areas mentioned above. This work will use that engine because of its modular design, existing feature richness and free software nature. 
+The Comunica query engine has been especially designed to be modular, allowing easy extensibility in the different areas mentioned above. This work will use that engine because of its modular design, existing feature richness and free software nature.

_papers/thesis-report/chapters/solid.typ

@@ -34,14 +34,14 @@ The resource access is often aligned with the CRUD operations, so each operation
 @wac was created with some extensibility in mind.
 One could use the #link("https://solidproject.org/TR/wac#extension-acl-mode")[Access Mode Extensions] to define a subclass of a default access mode, like for example `acl:read`.
 
-The specification contains an interestingly consideration:
+The specification contains an interesting consideration:
 #quote(block: true, quotes: true)[
   Servers are strongly discouraged from trusting the information returned by looking up an agent’s WebID for access control purposes. The server operator can also provide the server with other trusted information to include in the search for a reason to give the requester the access.
 ]
 
 This is interesting in the context of solid because it means we are discouraged from making access rules like:
 "Access is granted when the requestor is older than 21."
-This consideration was possibly written down to warn readers that servers cannot validate the data. 
+This consideration was possibly written down to warn readers that servers cannot validate the data.
 However, verifiable credentials might be able to change this view.
 Unfortunately, a @wac GitHub issue about this is open and inactive#footnote[https:\//github.com/solid/authorization-panel/issues/79].
 
@@ -60,7 +60,7 @@ An example @wac description is given below:
 ] .
 [
   acl:accessTo alice:card ;
-  acl:mode acl:Read, acl:Write ; 
+  acl:mode acl:Read, acl:Write ;
   acl:agent bob:card
 ] .
 ```
@@ -82,11 +82,11 @@ We also provide an @acp example:
 #text-example[
 ```turtle
 ex:accessControlResourceA
-  acp:resource ex:resourceX ;  
+  acp:resource ex:resourceX ;
   acp:accessControl [
-    acp:deny acl:Read, acl:Write ;  
+    acp:deny acl:Read, acl:Write ;
       acp:anyOf [
-        acp:client acp:PublicClient ;    
+        acp:client acp:PublicClient ;
       ] ;
       acp:noneOf [
         acp:client ex:clientC
@@ -96,7 +96,7 @@ ex:accessControlResourceA
 ]
 
 
-=== Conclusion 
+=== Conclusion
 
 We can conclude that both solutions are not perfect and that @acp is the more expressive specification.
 Beyond access control, the Solid Community is increasingly investigating usage control solutions.
@@ -112,9 +112,9 @@ To avoid this, a pod can have an index that can be used to speed up query execut
 === Type Index
 
 The first index proposed for Solid was the Type Indexes specification. //https://solid.github.io/type-indexes/
-It proposes two indexes, a private and a public index.
+It suggests two indexes, a private and a public index.
 Each index contains entries that map a certain @rdf type to a set of @http resources.
-The example below shows a type index that states that @rdf resources that have a tupe like `<s rdf:type vcard:AddressBook>` can be found at path `/public/contacts/myPublicAddressBook.ttl`.
+The example below shows a type index that states that @rdf resources that have a tuple like `<s rdf:type vcard:AddressBook>` can be found at path `/public/contacts/myPublicAddressBook.ttl`.
 #text-example[
 ```turtle
 @prefix solid: <http://www.w3.org/ns/solid/terms#>.
@@ -131,7 +131,7 @@ The example below shows a type index that states that @rdf resources that have a
 ```
 ]
 
-Besides the low granularity type indexes allow, they are inherently flawed because the access of resources cannot be grouped into "public" and "private" since more complex access control policies are the norm. 
+Besides the low granularity type indexes allow, they are inherently flawed because the access of resources cannot be grouped into "public" and "private" since more complex access control policies are the norm.
 
 === Shape Tree
 
@@ -193,7 +193,7 @@ In considers data to be stored in data registries, each indexed using a shape tr
 The specification also describes how one can request access to a resource and a way of storing what access rights have been granted.
 
 
-// Do I mention Solid Application Interoperability? It describes things like: Don't go to deep into your container structure. That's a peculiar claim, since SGV does encourage nesting. -> SGV could be used to generate multiple views though (requires top-level SGV) -> That would result in a view a user sees vs a interop compatible view.
+// Do I mention Solid Application Interoperability? It describes things like: Don't go too deep into your container structure. That's a peculiar claim, since SGV does encourage nesting. -> SGV could be used to generate multiple views though (requires top-level SGV) -> That would result in a view a user sees vs a interop compatible view.