Re: urn:solid: for prototyping predicates

On 2025-05-25 13:21, Melvin Carvalho wrote:
> 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

> 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 
> <https://lists.w3.org/Archives/Public/public-solid/2025May/0016.html>

Re "contextual clarity", then `urn:example:www.w3.org/ns/solid` (or any 
"unique"ish path for that matter) is entirely sufficient for those 
developers who can mint URNs but not HTTP URIs (as suggested but 
[citation needed]). That namespace would still allow intent and 
transition to be documented.

URIs do not leak data by default. Just because a URI is HTTP does not 
mean it gets dereferenced or tracked, nor implies there is something 
definitely meaningful behind it. If "privacy" (whatever that 
specifically entails) is a concern, then `urn:example:{uuid}`, 
`urn:uuid`, or `https://example.org/vocab#{uuid}` serves fine.

Privacy depends on application behaviour rather than URI syntax. If an 
app does not fetch or expose URIs, it does not matter whether they are 
`urn:solid`, `https:`, `data:`, ...

`urn:solid` lacks inherent privacy features. And just because it would 
not be globally dereferenceable, it should not be conflated with privacy.

If the community has bandwidth to make impactful efforts, it can focus 
on supporting stable HTTP URIs based on established practices, rather 
than introducing a new URN namespace without an established track record 
and spending enormous amount of energy educating developers and imposing 
tech debt.

-Sarven
https://csarven.ca/#i

Received on Sunday, 25 May 2025 12:26:42 UTC