Re: urn:solid: for prototyping predicates

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

> 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`
> <http://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}`
> <https://example.org/vocab#%7Buuid%7D> 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.
>

Thanks, Sarven, appreciate your perspective.

HTTP vocab URIs are designed to be dereferenced, and that brings real
value, inference, documentation, reuse.

URNs are more like JSON keys, in that they are "just a name": stable and
without resolution. That trade-off can be useful in early-stage work where
structure is needed but full vocab hosting isn’t practical yet.

Let’s agree to differ on this one, it’s been helpful in practice, and I
think developers should choose what suits their app best. Thanks again for
the thoughtful input.


>
> 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
>
>