Resource Identification

[uvdsl]

I'd like to follow up on @jeswr's call to action in #18 and #23 and note the related discussion around the terminology of resource in w3c/lws-ucs#160. I'd like to propose that we actively discuss the definition of a resource to build a shared understanding to put into the specification.

Our group's charter points to a clear and consistent definition via its two normative input documents:

• The Solid Protocol defines a resource as the target of an HTTP request identified by a URI [RFC9110].
• The Fedora API Specification adopts the W3C Linked Data Platform's definition, which is based on the Architecture of the World Wide Web [WEBARCH] and HTTP ([RFC7230], [RFC7231], [RFC7232]; superseded by [RFC9110]).

I propose that the group adopts a definition that is directly derived from our normative input documents.

One such example could be:
"A resource is identified by a URI [RFC3986] and is the target of an HTTP request [RFC9110]."

[gibsonf1]

I propose that the group adopts a definition that is directly derived from our normative input documents.

One such example could be: "A resource is identified by a URI [RFC3986] and is the target of an HTTP request [RFC9110]."

I definitely agree on having a very clear definition of Resource, especially the idea that a Resource can be anything with a URI that can be targeted via HTTP request (such as a single state that serializes as a triple if it has a unique URI and can be targeted via HTTP request).

The first link does not define a Resource at all but refers to it, and the second link has this: "The target of an HTTP request is called a "resource". HTTP does not limit the nature of a resource; it merely defines an interface that might be used to interact with resources."

What is interesting with the above is that the "resource" is about the target of the request and interface for interaction, whether the response is any data at all (such as a request not having permission and thus not getting anything back, etc).

From [RFC9110]: "A "representation" is information that is intended to reflect a past, current, or desired state of a given resource, in a format that can be readily communicated via the protocol. A representation consists of a set of representation metadata and a potentially unbounded stream of representation data (Section 8)."

Representation is perhaps the term we should be using in many cases instead of Resource to avoid confusion, as that is what a response provides if permissions are met? Effectively, a Resource is the capability to generate a Representation if all requirements are met, whereas the Representation is the actual thing (from a user perspective)

[w3cbot]

This was discussed during the #lws meeting on 16 June 2025.

View the transcript

Discussion: Resource identifiers

<uvdsl> w3c/lws-protocol#28

<gb> Issue 28 Resource Identification (by uvdsl)

laurens: there has been some discussion related in the protocol repository
… the editors would like to begin drafting some text
… one of the first and foundational item is that identifiers should be globally unique
… iri vs uri can be discussed later on

<gibsonf1> +1

laurens: seems we are mostly in consensus, but would like to hear thoughts

uvdsl: does the group want uri/iri ?

laurens: I don't want to start there, would like to start with whether the identifiers are globally unique

<dmitriz> what do you mean by 'atomic'?

laurens: by atomic, I mean that it can be completely identified in a single string

<Zakim> gibsonf, you wanted to say in addition to global unique, reachable via webn

laurens: unlike in SOAP where multiple elements (tuple) is needed

gibsonf: agree about globally unique, also reachable

ericP: is that the distinction between locator and identifiers?

uvdsl: for me I agree with gibsonf, that they are specifically using HTTP URIs (from charter docs)
… in SOAP, there is a tuple of identifier and operation

jackson: would like to push back on HTTP uris
… the current Solid CG Report requires HTTP URIs and it is hard to be compatible with DID
… limiting to HTTP URIs is very limiting

<dmitriz> what's the motivation for limiting the protocols, out of curiosity?

<gb> Issue 24 Reasons for separate rest bindings (by jeswr)

jackson: perhaps a provision in the specification to allow for certain protocols

tallted: pretty much in favor of the first part (global uniqueness)
… I question atomicity: there may be fragment identifiers
… relatedly, one goal of LWS is that a user can choose to move between providers
… if we limit to HTTP URIs, that requires additional infrastructure to not break links
… some providers allow vanity domains, but not all, esp financial institutions

<Zakim> uvdsl, you wanted to point to the bindings decision w3c/lws-protocol#24

uvdsl: this comes back to issue #24 related to bindings

<gb> Issue 24 Reasons for separate rest bindings (by jeswr)

uvdsl: i.e. whether to have binding or to tightly couple with HTTP
… limiting to HTTP URIs is restricting, it makes sense to limit to the transfer protocol. That doesn't limit to HTTP URIs
… there are DID methods that allow for HTTP transfer protocol

<Zakim> gibsonf, you wanted to say are we limiting representations to documents (re TallTed)

gibsonf: related to the document, we are not limiting a resource to a document
… I hope that is not the only thing to expect as a representation

<Zakim> dmitriz, you wanted to ask _why_ we're limiting protocols

dmitriz: why are we limiting URL protocols?
… what does that buy us

<Zakim> TallTed, you wanted to mention DID "universal resolver"

dmitriz: what problem does it solve?

tallted: there was also a concern raised about resolving DID methods for arbitrary methods
… the expectations from the DID WG that there will be libraries with global resolvers
… i.e. "resolve this did" and the client receives whatever the identifier references

<Zakim> uvdsl, you wanted to counterask

uvdsl: my perspective is that the specification should give implementers clear guidance

<gibsonf1> +1 to uvdsl

uvdsl: and without that guidance, we defeat the purpose of the spec

<dmitriz> that doesn't make any sense. do we also want to constrain the _packets_ to TCP only?

jackson: as an implementer, I'd want to make it easy, but I'd want a specific group to implement

laurens: we need to produce a test suite, and it needs to be testable
… any restriction needs to serve a purpose
… e.g. identifiers that are also locators
… I want a concrete requirement for that restriction

dmitriz: we are not going to constrain to TCP or how packets resovle over the wire
… we should say URLs and not specify the retrieval mechanism

<TallTed> +1 this may be premature restriction

ryey: I second dmitriz's perspective
… specifying URIs would be fine
… for the issue of portability, there are ways to approach this with relative URLs
… or a special header for where to resolve
… in the end there isn't a real issue for how the resource is identified

pchampin: I sypathize with dmitri's argument, that we want to rely on existing things that are specified elsewhere
… however, URIs are very abstract
… and we may want to characterize the properties of the URIs that we use
… e.g. resolvability

jackson: I don't think we should restrict only on HTTP
… if I am a client library, and someone has included a link to some location with a weird protocol
… e.g. if we say that we support 3 protocols and therefore all client libraries need to support all

<Zakim> uvdsl, you wanted to counter-argument flexibility should only be written into the spec if there are use cases

jackson: spec should have a mechanism to say these are the required protocols and here's how to expand

uvdsl: I agree about restricting to a list, I don't like a registry because it is too open
… I would push back on notion that we need to accommodate flexibility
… flexibility should only be part of the spec based on use cases, as outlined by the charter
… that will raise questions down the line

<Zakim> acoburn, you wanted to mention did and vc input documents

<dmitriz> text should be added to the spec only if it's solving a problem. restricting to http URLs is not solving any problem that was identified...

<laurens> acoburn: As I recall we have both the DID WG and VC WG and the documents they produce as inputs to our work

<laurens> ... that is part of the scope.

uvdsl: did and vc groups are to be aligned but they are not normatively listed as input documents
… arguing to be careful about what we write into the spec

<pchampin> uvdsl, I agree that we must not aim at flexibility for the sake of it; but I do believe that the flexibility discussed here (esp. for portability) is backed by use-cases

<uvdsl> pchampin, sure! Looking forward to seeing these use cases :)

laurens: vc and did documents are w3c recommendations and should be included in our consideration
… and some level of interop

<dmitriz> the burden of proof should be on why add restrictions in the first place.

ryey: a few weeks ago, the DID resolver WG was being created. Is DID resolution already a thing?

<Zakim> pchampin, you wanted to respond to ryey

<uvdsl> dmitriz, I disagree with that statement

pchampin: did resolution is not currently a recommendation
… it is a work item on the REC track
… so eventually would be a REC

ryey: are there rules of thumb for working with other W3C draft documents?

laurens: we have discussed this related to input documents

pchampin: we cannot have normative dependencies on doc that are much less mature
… we are allowed one level of difference
… we are currently behind did resolution
… unless they have problems, we shouldn't have an issue there

dmitriz: each did method has a definition for how a did is resolved
… still very strongly against restricting URI protocols
… imagine restricting to only HTTP but then HTTPS comes
… one example: this exact question is a problem in the VC community
… there is a spec for OpenID federation for issuer registries
… that specs restricts to HTTPS, trying to exclude DIDs
… all that ended up happening is that the VC group read the spec
… and either had to ignore spec restriction or fork the spec

laurens: I want to second that
… there are maintainability issues with too much restrictions without clear use cases

uvdsl: for updating the scheme of the URI, why not open up a version 2?
… the discussion in CG is very different
… I don't think the arguments presented would convince the community group

laurens: this is a discussion that could be made broader, but this needs to be clarified in this WG
… also reinstating a working group is not simple

jackson: I have an open mind, but I'd like more clarification
… if we have a specification with open URIs that include links using a random URI scheme
… and the technology encounters that, then a client library won't know how to resolve that
… what should happen to client libraries

dmitriz: the answer is always: "throw an error"

<uvdsl> so much for interoperability

dmitriz: i.e. what happens if you try to fetch a URL over HTTP and there is a network issue or server error
… but the principle is the same

<Zakim> acoburn, you wanted to note also that OpenID Federation is not W3C

<laurens> acoburn: OpenID and W3C are different governance bodies

<laurens> ... when crossing boundaries this isn't as straightforward

jackson: re: "throw an error", if there is a network error, the error handling is already baked in
… there should be a base level where every client library needs to implement

<dmitriz> sure, "at least implement HTTP" seems reasonable as a requirement.

jackson: would your proposal be "at least implement these protocols"?
… or that we shouldn't even mention http/did in the specification

uvdsl: re "throw an error" flies in the face of the solid charter
… this makes interoperability challenging

<dmitriz> @uvdsl -- part of our charter is to define error conditions.

<gb> @uvdsl

uvdsl: you can have spec compliant systems that don't interoperate

<Zakim> ericP, you wanted to describe requirements (MUST impelement) in terms of branding

uvdsl: I don't think this aligns with the goals of the charter

ericP: we should describe the optional and required protocols as "branding"

<uvdsl> sure, so you suggest prioritising error conditions over interoperability?

ericP: if someone goes to one place to get a server and elsewhere to get a client, there is a desire that they talk to each other

<dmitriz> I'm suggesting that restricting url protocols does not buy you interoperability. all that it buys you is -- either the spec gets forked, or implementers will just ignore it.

ericP: the "box" could be lws+did

<uvdsl> dmitriz, so you say that agreeing on a transport protocol does not induce interoperability? That is an interesting take.

<dmitriz> this is not hypothetical, either -- this JUST happened with open id federation.

ericP: if someone creates a resource with HTTP and then performs a GET over SPARQL, you want to be able to say that the resource is the same

<dmitriz> @uvdsl - we're not talking about transport protocol though, notice. we're not talking about TCP or UDP. which is my point.

<gb> @uvdsl

<dmitriz> we're talking about unnecessary URL protocol restriction.

jackson: that seems acceptable: a few requirements, but don't invalidate other implementations that use others

<uvdsl> Yeah, we were talking about HTTP. And agreeing on HTTP does not induce interoperability?

laurens: we need to be mindful of layering of future applications/domains on top of LWS

<uvdsl> You are right, HTTP is of course not transport.

<laurens> PROPOSAL: Protocol document to include HTTP resource identifiers despite not yet having been formalized as a requirement in the Use Cases & Requirements WG Note.

laurens: there was a discussion to use HTTP URIs in the protocol document

<ericP> +1

<eBremer> +1

<laurens> +1

<acoburn> +1

<TallTed> +1

<bendm> +1

<jeswr> +1

<gibsonf1> +1

<dmitriz> +1

<uvdsl> +1

<pchampin> +1

<RazaN> +1

<jackson> +1

<ryey> +1

RESOLUTION: Protocol document to include HTTP resource identifiers despite not yet having been formalized as a requirement in the Use Cases & Requirements WG Note.

<uvdsl> w3c/lws-protocol#28

<gb> Issue 28 Resource Identification (by uvdsl)

uvdsl: having arguments in writing and being able to discuss async would be appreciated

laurens: yes, we very much encourage that

<pchampin> uvdsl, I will add a pointer to the minutes of the discussions we just had in issue 28

hadrian: applied for IE status, began re-working some UCR docs

<uvdsl> Okay, thank you pchampin !

---

[jaxoncreed]

I'll put the 2 cents I contributed at the meeting here: there MUST be a set of protocols that are required support in the specification (https/http, maybe some did methods). Without this there is no way to guarantee that implemented systems will actually be interoperable. I think it would be fine to have more than just http as long as it's dictated as a MUST implement.

Having an optional condition that says any uri scheme can be used is acceptable, but it would be acknowledged that any implementers depending on this are doing so at their own risk

[jacoscaz]

laurens: we need to produce a test suite, and it needs to be testable
… any restriction needs to serve a purpose
… e.g. identifiers that are also locators
… I want a concrete requirement for that restriction

+1 this may be premature restriction

Premature flexibility can be just as damaging as premature restrictions due to the additional complexity it brings to a spec, which in turn directly affects adoption and market penetration.

If concrete requirements must be presented in order to argue for restrictions, something which I agree with, the same should also happen when arguing for flexibility. Flexibility, IMHO, is not intrinsically a virtue on its own.

RESOLUTION: Protocol document to include HTTP resource identifiers despite not yet having been formalized as a requirement in the Use Cases & Requirements WG Note.

Just to clarify, does "HTTP resource identifiers" mean "any identifier (HTTP URLs, DIDs with the web method) that can ultimately result in dereferencing a document / resource over HTTP"?

[acoburn]

Just to clarify, does "HTTP resource identifiers" mean "any identifier (HTTP URLs, DIDs with the web method) that can ultimately result in dereferencing a document / resource over HTTP"?

This means URIs that use the http(s) scheme. https://example.com would be one example. did:web:example.com would not.

[jacoscaz]

This means URIs that use the http(s) scheme. https://example.com would be one example. did:web:example.com would not.

Thank you for the clarification @acoburn . In this case, I personally welcome the outcome of this discussion :)

[pchampin]

Reviving this issue, as it came up as an aftermath of the CRUD discussion (#37).

I would refrain from redefining the term "resource", but rather use the (very generic) definition from webarch.

However, there are different subsets of resources that are of interest to the LWS specification, some of which deserve to be defined in the spec.

• the notion of information resource (also from webarch) proved useful in the recent discussions, and should maybe be explicitly referred to in the spec

• the different categories of resources stored on a LWS storage should also, IMO, be explicitly and clearly defined. Initial CRUD with proposed metadata handling #37 introduced, somehow, such categories ("Resources MUST be classified as 'DataResource', 'Container', or 'MetadataResource' via metadata types.") but did not provide explicit definition of each category.

[gibsonf1]

@pchampin The confusing part to me is 'DataResource' vs 'MetadataResource'. In the TwinPod example, all resources have data about them directly linked to that resource URI. For example, if a file is requested from a given URI, depending on representation in the Accept header, either the file is delivered (based on the hasVersion triple for that File's URI) or the data on that file at the same URI is delivered, there isn't a separate metadata resource for the file, its just the same Data as all resources but reponse representation changes based on user request.

[pchampin]

@gibsonf1 yep, that's why I believe we need proper definitions :)

To your question, my understanding is that MetadataResource are governed by §9.1 Metadata -- but that's getting out-of-scope for this issue.

[uvdsl]

Thank you, @pchampin, clear definition of terminology is a must.

I would refrain from redefining the term "resource"

I agree, I personally prefer the terminology of resource / information resource from [WEBARCH] in conceptual discussions.

My initial proposal was merely an attempt to consolidate the technical definitions from the input documents.

[w3cbot]

This was discussed during the #lws meeting on 26 January 2026.

View the transcript

w3c/lws-protocol#28 Resource Identification (by uvdsl)

acoburn: on #28, mostly on terminology? uvdsl?

uvdsl: yes, but tied to #24, regarding the minimum to implement for the transport protocol of the LWS protocol

acoburn: I'll label it as needs discussion

---

[acoburn]

Does the current terminology section address this issue?