profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/RubenVerborgh/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Ruben Verborgh RubenVerborgh Belgium | United Kingdom https://ruben.verborgh.org/ Professor of Decentralized Web technology. Querying the Web of Linked Data. #decentralization #WebWeWant

follow-redirects/follow-redirects 357

Node.js module that automatically follows HTTP(S) redirects

comunica/comunica 233

📬 A knowledge graph querying framework for JavaScript

LDflex/LDflex 135

A JavaScript DSL for querying Linked Data on the Web

chaijs/chai-things 102

Chai support for assertions on array elements

inrupt/solid-client-authn-js 35

A client library for authenticating with Solid

LDflex/LDflex-Comunica 13

Comunica query engine support for the LDflex language

inrupt/public-documentation 4

Anything open to the public that is related to documentation, code examples, standards.

kezike/solid-pg 3

Solid Playground - Solid Single-Page Playground Application

comunica/generate-comunica 2

🎛 Generators for comunica packages

inrupt/solid-common-vocab-js 2

A library providing JavaScript objects to represent the individual terms (i.e. the classes and properties) defined in RDF vocabularies.

Pull request review commentsolid/notifications-panel

Init Solid Notifications Use Cases and Requirements

+<!DOCTYPE html>+<html lang="en" xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">+  <head>+    <meta charset="utf-8" />+    <title>Solid Notifications Use Cases and Requirements</title>+    <meta content="width=device-width, initial-scale=1" name="viewport" />+    <link href="https://www.w3.org/StyleSheets/TR/2016/W3C-ED" media="all" rel="stylesheet" title="W3C-ED" />+<style>+body {+counter-reset:section;+counter-reset:sub-section;+}+em.rfc2119 { color: #900; }+code, samp { color: #c83500; }+pre code, pre samp { color: #000; }+dfn { font-weight:inherit; }+.do.fragment a { border-bottom:0; }+.do.fragment a:hover { background:none; border-bottom:0; }+section figure pre { margin:1em 0; display:block; }+cite .bibref { font-style: normal; }+.tabs nav ul li { margin:0; }+div.issue, div.note, div.warning {+clear: both;+margin: 1em 0;+padding: 1em 1.2em 0.5em;+position: relative;+}+div.issue h3, div.note h3,+div.issue h4, div.note h4,+div.issue h5, div.note h5 {+margin:0;+font-weight:normal;+font-style:normal;+}+div.issue h3 > span, div.note h3 > span,+div.issue h4 > span, div.note h4 > span,+div.issue h5 > span, div.note h5 > span {+text-transform: uppercase;+}+div.issue h3, div.issue h4, div.issue h5 {+color:#ae1e1e;+}+div.note h3, div.note h4, div.note h5 {+color:#178217;+}+figure .example-h {+margin-top:0;+text-align: left;+color:#827017;+}+figure .example-h > span {+text-transform: uppercase;+}++header address a[href] {+float: right;+margin: 1rem 0 0.2rem 0.4rem;+background: transparent none repeat scroll 0 0;+border: medium none;+text-decoration: none;+}+header address img[src*="logos/W3C"] {+background: #1a5e9a none repeat scroll 0 0;+border-color: #1a5e9a;+border-image: none;+border-radius: 0.4rem;+border-style: solid;+border-width: 0.65rem 0.7rem 0.6rem;+color: white;+display: block;+font-weight: bold;+}+main article > h1 {+font-size: 220%;+font-weight:bold;+}++article section:not([id=abstract]):not([id=sotd]):not([id=references]):not([id=appendix]):not([id=acknowledgements]):not([id=change-log]):not([id=exit-criteria]) {+counter-increment:section;+counter-reset:sub-section;+}+article section:not([id=abstract]):not([id=sotd]):not([id=references]):not([id=appendix]):not([id=acknowledgements]):not([id=change-log]) section:not([id$=references]):not([id=exit-criteria]) {+counter-increment:sub-section;+counter-reset:sub-sub-section;+}+article section:not([id=abstract]):not([id=sotd]):not([id=references]):not([id=appendix]):not([id=acknowledgements]):not([id=change-log]) section:not([id$=references]):not([id=exit-criteria]) section {+counter-increment:sub-sub-section;+counter-reset:sub-sub-sub-section;+}+article section:not([id=abstract]):not([id=sotd]):not([id=references]):not([id=appendix]):not([id=acknowledgements]):not([id=change-log]) section:not([id$=references]):not([id=exit-criteria]) section section {+counter-increment:sub-sub-sub-section;+counter-reset:sub-sub-sub-sub-section;+}+article section:not([id=abstract]):not([id=sotd]):not([id=references]):not([id=appendix]):not([id=acknowledgements]):not([id=change-log]):not([id=exit-criteria]):not([id^=table-of-]) > h2:before {+content:counter(section) ".\00a0";+}+section:not([id$=references]):not([id^=change-log]):not([id=exit-criteria]) > h3:before {+content:counter(section) "." counter(sub-section) "\00a0";+}+section > h4:before {+content:counter(section)"." counter(sub-section) "." counter(sub-sub-section) "\00a0";+}+#acknowledgements ul { padding: 0; margin:0 }+#acknowledgements li { display:inline; }+#acknowledgements li:after { content: ", "; }+#acknowledgements li:last-child:after { content: ""; }++aside.do { overflow:inherit; }+aside.do blockquote {+padding: 0; border: 0; margin: 0;+}+dl[id^="document-"] ul {+padding-left:0;+list-style-type:none;+}+dl [rel~="odrl:action"],+dl [rel~="odrl:action"] li {+display: inline;+}+dl [rel~="odrl:action"] li:after {+content: ",";+}+dl [rel~="odrl:action"] li:last-child:after {+content: "";+}++table {+width:100%;+margin-top:1em;+text-align:left;+border-collapse:collapse;+font-variant-numeric: lining-nums tabular-nums;+overflow: auto;+}+table + table {+margin-top:2em;+}+caption {+text-align:left;+padding:0 0.25em 0.25em;+}+caption, tbody, tfoot {+border-bottom:2pt solid #000;+}+thead,+thead th[colspan] {+border-bottom:1pt solid #000;+}++[rowspan] { vertical-align: bottom; }+tbody [rowspan] { vertical-align: middle; }++tbody th[scope="rowgroup"] {+border-bottom:3pt double #000;+}++th, td {+padding:0.25em;+font-size:0.923em;+word-wrap:normal;+}+table ul,+table ol,+table li,+table p,+table dd {+margin:0;+text-align:left;+}+tfoot td > * + * {+margin-top:1em;+}++tfoot dl.abbr dt,+tfoot dl.abbr dd {+display:inline;+text-transform:none;+}+tfoot dl.abbr dd {+margin-left:0;+}+tfoot dl.abbr dd:after {+content:"\A";+white-space:pre;+}+tfoot dl.abbr dt:after {+content:": ";+}+tfoot dl.abbr {+-webkit-column-count:2;+-moz-column-count:2;+column-count:2;+}+tfoot dl.abbr dt {+font-weight:bold;+}++table[typeof~="qb:DataSet"] tbody tr:not([typeof~="earl:Assertion"]) td {+text-align:center;+}+table[typeof~="qb:DataSet"] tbody tr:not([typeof~="earl:Assertion"]) th,+table[typeof~="qb:DataSet"] tbody tr:not([typeof~="earl:Assertion"]) td {+border: 1px solid #ccc;+border-left-color: #eee;+border-right-color: #eee;+}+</style>+    <link href="https://dokie.li/media/css/dokieli.css" media="all" rel="stylesheet" />+    <script src="https://dokie.li/scripts/dokieli.js"></script>

The document will work (human- and machine-readable) even if recipient is unable to access or use the CSS or JavaScript.

In that case, consider

    <script src="https://dokie.li/scripts/dokieli.js" defer></script>

and, for lack of defer on stylesheets, for the dokieli.js to insert https://dokie.li/media/css/dokieli.css instead.

csarven

comment created time in 6 hours

PullRequestReviewEvent

issue commentsolid/community-server-recipes

Penny config: How can I create a new pod?

Good catch! but I still don't get what I would expect:

Haha woops, that's not good indeed. I will check up on that.

I feel that with the penny recipe what I get is not so different that a simple penny instance. I don't see how I can access the default CSS feature ( mainly pod creation )

Understood; we might want to set it up such that a default index.html is created if none is present.

joeitu

comment created time in 10 hours

issue commentsolid/community-server-recipes

Penny config: How can I create a new pod?

reached to localhost:3000/idp/register return an error

That should be http://localhost:3000/idp/register/ (with a slash at the end).

Where is the link without the slash listed?

Being able to see the default CSS index page, with link to the sign-up page. […] Having penny interface only when accessing a pod url, like localhost:3000/mypodname/

That is possible, but perhaps then in a separate configuration file as to not confuse people.

joeitu

comment created time in 10 hours

issue commentsolid/specification

Alternative update support with N3 patch

The accept-patch header of course allows us a smooth transition, with servers advertising what they support, and being able to support both for a time.

:+1:

I'd question the "0.9" tag as release 0.9 is documenting existing solid which works now.

I would argue it is part of existing Solid, since it works in NSS >= 4.0 and a couple of other libraries.

So 0.9 should document our SPARQL/Update-like-thing, and a future one introduce this.

The issue is that SPARQL/UPDATE as implemented in NSS cannot go into 0.9 directly, because it conflicts with other standards. So we would need to adjust it in any case (#320 or #330).

Whereas N3 Patch can go straight into 0.9 if we want, because it has been implemented for 4 years and does not have such conflicts.

Is the Accept-patch: value then text/n3 ?

Indeed.

RubenVerborgh

comment created time in 10 hours

issue openedsolid/notifications

Why do notifications use JSON-LD?

created time in 10 hours

issue openedsolid/specification

Alternative update support with N3 patch

Context

The Solid protocol specifies a mechanism to update resources via HTTP PATCH (https://github.com/solid/specification/issues/85) whereby the contents of the change are expressed in the HTTP body.

Description of current status and problems

The currently proposed media type for these updates is that of the SPARQL 1.1 Update specification. However, Solid servers deviate from this specification in important ways:

  • Only a subset of the SPARQL 1.1 Update language is supported:
    • https://github.com/solid/specification/issues/125
    • https://github.com/solid/specification/pull/320
  • There is a desire to have different matching semantics:
    • https://github.com/solid/specification/issues/322
    • https://github.com/solid/solid-spec/pull/193
    • https://github.com/solid-archive/query-panel/issues/3

A currently proposal suggests to use a different (but SPARQL-inspired) syntax altogether in order to avoid confusion with the actual SPARQL 1.1 Update language:

  • https://github.com/solid/specification/pull/330

Whereas I understand the reasoning behind that, I see a couple of problems:

  • There are no existing server or client implementations
    • All servers would have to be changed
    • All clients would have to be changed
  • The proposed syntax is non-standard
    • This is concerning from a Solid philosophy where we strive to use standards
    • It also means that implementations cannot reuse existing stacks, but have to roll their own

Proposed solution

My proposal is an N3 patch format as a solution for the 0.9 release.

Advantages

  • Support has been implemented and tested in NSS since 2017
  • RDFlib.js code exists for it
    • So JavaScript clients can be migrated easily with an RDFlib.js upgrade
  • It is a largely standards-based approach
    • Off-the-shelf parsers already exist for multiple programming languages
  • We are in control of the semantics
    • And the semantics are extensible because it is an RDF format

Disadvantages

  • N3 is not an actual W3C standard
  • We still require changes to clients and servers

Examples

A working example patch looks as follows (MIME type text/n3):

@prefix solid: <http://www.w3.org/ns/solid/terms#>

<> solid:patches <https://tim.localhost:7777/read-write.ttl>;
   solid:where   { ?a <y> <z>. };
   solid:inserts { ?a <y> <z>. };
   solid:deletes { ?a <b> <c>. }.

Thee above terms are all defined in https://www.w3.org/ns/solid/terms.

More examples are available in the tests I have written for NSS; they can also be tried live against any NSS >=4.x server.

created time in 16 hours

issue commentsolid/solid-oidc

Clarify implicitly trusted OIDC issuer

Are all components for the specification being designed in a way that doesn't depend on publicly accessible WebID Document?

Let me phrase it differently: I don't think many depend on it.

RubenVerborgh

comment created time in a day

pull request commentsolid/community-server

Convert representations if explicitly requested (not via */*)

One case I'm thinking of is a resource with content-type application/ld+json. After this change you will get a 501 when sending an application/json accept header, while this would previously work.

Can re-add that one. But that would indeed not work for Turtle then (and probably never has).

RubenVerborgh

comment created time in a day

pull request commentsolid/community-server

Convert representations if explicitly requested (not via */*)

Btw, is there a reason this is marked as a minor semver change instead of a patch in that case?

New API feature: ignoreWildcards on IfNeededConverter.

RubenVerborgh

comment created time in a day

pull request commentsolid/community-server

Convert representations if explicitly requested (not via */*)

Due to the ContentTypeReplacer being removed from the default config, several cases that would have worked on the server in the past will not work anymore now.

I think it's okay. The important cases still work; the ones that do not were broken before. Conneg is better after this.

RubenVerborgh

comment created time in a day

pull request commentsolid/community-server

fix: Allow URLs with multiple leading slashes.

I'm fine with that behavior, in the sense that implementation-specific is ok.

RubenVerborgh

comment created time in a day

issue commentsolid/specification

Specify container description

Further clarification: depending on the backend, CSS will also provide dc:modified, posix:mtime, and posix:size. Here is for instance the result with a filesystem backend:

  • CSS
<foo.txt> a ldp:Resource;
    <http://purl.org/dc/terms/modified> "2021-10-25T09:10:05.000Z"^^xsd:dateTime .
    <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.w3.org/ns/ldp#Resource> .
    <http://www.w3.org/ns/posix/stat#mtime> 1635153005 .
    <http://www.w3.org/ns/posix/stat#size> 4
csarven

comment created time in a day

issue commentsolid/community-server

How to edit a resource's metadata

There is some metadata we don't want users to edit

I think we should protect those; just like we protect container listings.

All of the above is also only about Link headers, do we also care about other headers?

I personally don't; although maybe some RDF could translate into non-Link headers.

Another issue is of course that this would be a specific implementation for CSS which is going to be annoying for app developers if it is different everywhere.

I think this belongs in an experimental module of CSS, not in the main code. And if we are happy with the way it works, we should propose it to the spec. This is one of the important functions of CSS: informing the spec through open implementation.

woutslabbinck

comment created time in a day

delete branch solid/community-server

delete branch : fix/leading-slashes

delete time in a day

PR merged solid/community-server

fix: Allow URLs with multiple leading slashes.

Fixes https://github.com/solid/community-server/issues/1025

+11 -6

3 comments

2 changed files

RubenVerborgh

pr closed time in a day

push eventsolid/community-server

Ruben Verborgh

commit sha b42150cf52212ff2d6ba76e0db78faf71b10db89

fix: Allow URLs with multiple leading slashes. Fixes https://github.com/solid/community-server/issues/1025

view details

push time in a day

issue closedsolid/community-server

Multiple leading slashes in path confuse the server

When running the default server:

$ curl http://localhost:3000//
TypeError: Invalid URL
$ curl http://localhost:3000//////
TypeError: Invalid URL
$ curl http://localhost:3000//hello
{"name":"InternalServerError","message":"The identifier http://hello/ is outside the configured identifier space.","statusCode":500,"errorCode":"E0001","details":{"path":"http://hello/"}}
$ curl http://localhost:3000/////////hello
{"name":"InternalServerError","message":"The identifier http://localhost:3000///////hello is outside the configured identifier space.","statusCode":500,"errorCode":"E0001","details":{"path":"http://hello/"}}

closed time in a day

RubenVerborgh

pull request commentsolid/community-server

fix: Allow URLs with multiple leading slashes.

To be more specific, we need an exact URL for DPoP validation, currently configured in config/ldp/authentication/dpop-bearer.json.

We also happen to use OriginalUrlExtractor as targetExtractor in the request parser (config/ldp/handler/components/request-parser.json), but that is not a necessity. And note we already drop the query string there, so no longer really the original URL. We could easily turn it into a NormalizedUrlExtractor that does work on the slashes etc.

RubenVerborgh

comment created time in a day

pull request commentsolid/community-server

fix: Allow URLs with multiple leading slashes.

Looking around a bit it seems that it is not that uncommon for libraries to combine multiple slashes.

Yes, but here the goal is specifically to reconstruct the original URL, whatever it was. So if the request was made to ///// then we should not normalize if the goal is to obtain the original URL.

we should just use the joinUrl function since that is its job.

So I would argue that joinUrl has another job, which does include normalization.

Internally for CSS there is also the question how we should represent such URLs

We should definitely normalize for most, if not all, backends. Shall we turn that into a separate issue?

RubenVerborgh

comment created time in a day

issue commentsolid/community-server

How to edit a resource's metadata

Note: this only works for a limited amount of predicates, which have to be manually placed in https://github.com/solid/community-server/blob/2e4589938f4475a1a776dbc82ca4fd1501360764/config/ldp/metadata-parser/parsers/link.json List of predicates that can be placed in rel:

I just want to note that this is by design; because the client might have other reasons for adding Link headers. In other words: the request containing Link headers in a PUT/POST by itself is not a sign that the server should attach them to the resource.

However, some operations need to happen simultaneously; i.e., when creating a container, the appropriate Link headers have to be set during that creation and cannot be amended later through other actions (such as .meta).


In terms of approaches, I myself have always favored quad-based representations with a dedicated metadata graph, as we have done for the design of Triple Pattern Fragments. But we currently do not have wider support for this, even though it would address the simultaneity requirement.

woutslabbinck

comment created time in a day

issue commentsolid/community-server

Add support for SHACL shape constraints

But how should this triple be initialised in that container? It is quite simple to add functionality to PATCH the container with link headers to add this triple. However, an other issues arises then: how do you then delete this triple when no more shape validation should occur?

That's an interesting problem; let us create an extra issue for that: How to edit a resource's metadata?

My proposal would be to expose the .meta link, and then do regular RDF editing on that resource. That approach works for containers as well as documents. But there are other options; let's discuss them in that issue.

Dexagod

comment created time in 2 days

push eventsolid/community-server

Ruben Verborgh

commit sha b42150cf52212ff2d6ba76e0db78faf71b10db89

fix: Allow URLs with multiple leading slashes. Fixes https://github.com/solid/community-server/issues/1025

view details

push time in 2 days

PR opened solid/community-server

Reviewers
fix: Allow URLs with multiple leading slashes.

Fixes https://github.com/solid/community-server/issues/1025

+11 -6

0 comment

2 changed files

pr created time in 2 days

create barnchsolid/community-server

branch : fix/leading-slashes

created branch time in 2 days

push eventsolid/solid-oidc

Ruben Verborgh

commit sha d3c1614d826620773b647953e764dda24aece63b

Clarify which issuers are implicitly trusted. Fixes https://github.com/solid/solid-oidc/issues/51

view details

push time in 2 days