csarven on uri-resources-agent-origin
csarven on editorconfig
csarven on inm-asteriks
csarven on wac-ed-follow-up
csarven on 2021-10-27
csarven on resourcetype
csarven on remove-client-check-root-path
csarven on main
Remove optional advisement rely… (compare)
RubenVerborgh on n3-patch
Simplify wording. Co-authored-… (compare)
<WebID>as a Class... and wrote "an Agent" to hint at the class.. a person, an org.. a software agent.. as the definition of solid:account says "A solid account belonging to an Agent." .. so, yes, foaf:Agent, schema:SoftwareAgent, vCard:WebId fits.
:point_up: January 4, 2021 9:43 PM
Zero: Stop thinking in terms of LDP
Btw. I think one should not stop thinking it terms of LDP, rather think in terms of refinements of LDP. There's a lot of work that went into LDP (5 years with major players, a test suite and a spec) and we should not dismiss that work.
Those points by @acoburn show Solid be an extension of LDP. (And one of those points I would say needs to be very carefully phrased as it could be problematic.)
We have a problem that we have dropped solud discovery it seems. It is the first client-client spec so in a wag the most urgent after the solid protocol. We have chat apps and contacts stuff which uses the type indexes to find chats and address books etc through the type indexes and that spec is small but important.
discovery is included in draft from interoperability panel, especially:
both aim to take into account access control in process of data discovery
We have chat apps and contacts stuff which uses the type indexes to find chats and address books etc through the type indexes
I thought it refers to https://github.com/solid/solid/blob/master/proposals/data-discovery.md#type-index-registry
From the description of a Data Registry:
A Data Registry can be used for basic discovery, but it is not designed nor intended to be an efficient means to query or index data. However, it is intended to be used as reliable source data for different query engines or indexing schemes.
<img src="..." height="100" width="...">code. This is part of the github raw html extensions capability. It does not actually give an example with img size. But I found an issue jgm/pandoc#2554 and I have tried it previously on some other markdown pages of github.
The LDP test suite is an interesting topic. There are problems with it (aside from the fact that it will not compile on any currently supported version of Java). Basically: the test suite project is no longer maintained.
With Trellis, I made the decision years ago to fork that codebase and maintain that fork independently. https://github.com/trellis-ldp/ldp-testsuite
As for divergences with LDP, the Trellis project publishes test reports for BC, DC and IC conformance. The BC report is here: https://www.trellisldp.org/ldp/report/basic.html. You can see the MUST failures all relate to OPTIONS requests (which is intentional). The SHOULD and MAY failures are also intentional, but those are more in the category of design decisions than a problem with the spec. For example: w/r/t changing containment triples via PUT, rather than return a 412, Trellis just ignores those triples; it is a pragmatic decision to make client interactions considerably less “picky”. Consider, for instance, a client does a GET of a container and then modifies a dc:description triple, and then PUTs the resource back. If, in the meantime, another client has added or deleted a resource in that container, the PUT would technically be trying to modify those triples even though that’s not the intention. If the client wants to avoid any “lost update” data, the client can use ETags. Plus, LDP explicitly says that a server can ignore server-managed triples that a client sends.