Re: urn:solid: for prototyping predicates

ne 25. 5. 2025 v 12:57 odesílatel Sarven Capadisli <info@csarven.ca> napsal:

> On 2025-05-22 07:29, Melvin Carvalho wrote:
> > https://solid-lite.github.io/urn-solid/ <https://solid-lite.github.io/
> > urn-solid/>
> >
> > Would love any thoughts!
>
>
> One will still have to "mint" URIs using `urn:solid`, and `urn:solid` is
> not an IANA registered namespace (not to mention the cost of pursuing
> that).
>

Thanks, I will look into this further.


>
> The primary use case is already covered by `urn:example` if one is set
> on minting a URI intended for temporary or testing/experimentation
> purposes, if "minting" HTTP URIs are for some reason not possible for
> said developers but somehow minting URN URIs are possible.
>

I did try urn:example early on, but it felt too generic to indicate intent.
urn:solid gives us contextual clarity and encourages community reuse during
prototyping. A scoped prefix invites a future upgrade path, unlike a
catch-all like example


>
> There is a difference between using a URI as an identifier and
> dereferencing it. If dereferencing is not needed, one can already use
> HTTP URIs *today*. Having an HTTP URI does not require it to be fetched.
> HTTP URIs can later be upgraded to resolve to URLs. Any placeholder URI,
> such as one based on `example.org` or even `localhost`, will suffice.
>
> `urn:solid` has the same risks as any unscoped term. Any two authors
> could independently mint, for example, `urn:solid:foo`, without any
> guarantee the term means the same thing. That's known as a URI
> collision. So, coordination is required to ensure consistent meaning.
> But if developers are capable of that, they can already participate in
> the broader community to align on terminology. Hence, no need for
> `urn:solid` whatsoever.
>

[image: image.png]

I prepared this handy table of trade offs as explained in [1], including
privacy trade-offs.

[1] https://lists.w3.org/Archives/Public/public-solid/2025May/0016.html


>
> That's all aside from the issue of promoting bad suggestions to the
> developer community like tightly coupling an application to a
> Solid-specific URI (even if that can be changed later). If someone
> chooses to spend time chasing `urn:solid` registration, writing
> (LLM-generated) documentation, or promoting its use, that effort could
> be better spent applying existing best practices. But I suppose each
> person can decide how to spend their time.
>
> Convenience is being used here to justify deviation from established
> standards, without addressing long-term impact or technical debt. If
> someone wants to use `urn:solid` in their own Solid Lite experiments,
> that's their choice but it shouldn't impose a burden on the broader
> community.
>
> There's no compelling evidence that `urn:solid` is lighter, better, or
> more aligned with Solid or Web architecture than existing alternatives.
>
> So all of that put together: `urn:solid` is a distraction, a dead end,
> potentially damaging/fragmenting, and not particularly useful especially
> when alternatives already cover the use case and offer a path that's
> more robust and standards-aligned.
>
> Just my two cents.
>
> -Sarven
> https://csarven.ca/#i
>