Linked data in html files

Use Solid
21

an unauthenticated fetch might result in read but not write permissions

A fetch can be for read or write: GET, PATCH, POST

22

Yeah, but if Iā€™m trying to read the current access levels (e.g. by looking at the Link headers), Iā€™ll need to do both an unauthenticated and an authenticated GET, right?

1 Like
23

Depending on what you are trying to achieve, that is one approach. An authorization server will also (typically) provide that information with fewer round-trips

24

Why is a linked data client not sending an accept header?

Because the specification says that Solid Servers should send turtle unless otherwise specified. Yes you have a right to move the profile out of the Solid Server, but making it act differently form profiles that are on Solid Servers is extremely inconvenient for developers.

2 Likes
25

Because the specification says that Solid Servers should send turtle unless otherwise specified.

That is true of Solid Resources.

But that is not true of non-Solid Resources. And a WebID profile is not necessarily a Solid Resource. In some cases (e.g. NSS, CSS) it is a Solid Resource. But that is not an assumption a client should make.

26

Your document can function as a non-Solid resource as much as it wants. No one is disputing that. What I am disputing is your decision to also make it non-functional as a Solid resource.

1 Like
27

If a resource is a non-Solid resource, a client should interact with it as a non-Solid resource. Is there really any debate about that?

Why would a client assume that a non-Solid resource behaves like a Solid resource?

28

If a Solid WebID Profile Document, arguably the most important resource for any Solid operation, does not function as a Solid resource, something is broken.

1 Like
29

Why would a client assume that a non-Solid resource behaves like a Solid resource?

@acoburn I agree with jeffz that this is more about an assumption, rather than a fact. I think it is reasonable for developers to assume the WebId is a solid resource. Could you elaborate on why it isnā€™t and why it matters to differentiate?

30

Iā€™ve created an issue about this on the WebID Profile Specification repo : Must WebID doc return RDF without a header? Ā· Issue #38 Ā· solid/webid-profile Ā· GitHub.

1 Like
31

thank you @jeffz

32

@anon85132706 we need to be very careful about assumptions when discussing specifications.

First, there are several layers that shouldnā€™t be confused, especially the distinction between protocol and data model.

The Solid Protocol specification defines a particular protocol for interacting with linked data resources and managing their lifecycle using a particular API. Outside of the use of ldp:contains there is no data model defined by the Solid Specification.

The WebID draft specification, on the other hand, defines no protocol but does describe a minimal data model. The Solid WebID draft specification further refines that WebID data model by adding some additional requirements. Still, there is no protocol defined beyond the very basics of HTTP (i.e. require support for GET). This is all well and good because we are not conflating things: the best specifications IMO keep protocols and data models separate.

The Solid-OIDC describes a particular data model requirement that is added to WebID Profile documents (solid:oidcIssuer) but otherwise relies on that minimal HTTP based protocol defined by the WebID draft specification.

Yes, WebID profiles are important, but itā€™s the data model that is important, not the Solid Protocol. And nowhere in any Solid-related specification does it state that a WebID document must be managed in a Solid Storage (this is also a good thing for many reasons). If the WebID profile document is managed in a Solid Storage, then it would need to conform to the Solid Protocol. If it is not stored in a Solid Storage, then there is no requirement for the resource to conform to the Solid Protocol. There is, however, always a requirement that a WebID Profile resource conforms to the WebID draft specification.

I would turn your question around: why would I assume a WebID resource is a Solid resource?

When building linked data applications, an app may interact with many, many resources spread across the Web. Some of those will be RDF, some will not. Some will be hosted by a Solid Storage (and therefore conform to the Solid Protocol API), some will not. Apps that make use of SPARQL, QPF, Verifiable Credentials, IIIF, or any of the myriad APIs available on the Web will need to be able to navigate between Solid resources and non-Solid resources. This is just one example of navigating between resources that conform to different underlying specifications.

Ensuring that a Solid app can work with different resource types is one way to make Solid work with both the existing Web while also supporting the Web we are building with Solid.

3 Likes
33

A quick update: weā€™ve released a fix to the OPā€™s issue: ESS now serves the WebID as text/turtle unless negotiated otherwise; Browsers when visiting the WebID will still see html, as they send an Accept: text/html, / type header, but fetch will return turtle

5 Likes