- From: Melvin Carvalho <melvincarvalho@gmail.com>
- Date: Mon, 26 May 2025 11:20:23 +0200
- To: Christoph Braun <braun3@fzi.de>
- Cc: public-solid@w3.org
- Message-ID: <CAKaEYhLbp9B0tLB2s6VkieoNEotKbxyYJwZWq-yD2TZrg03PCg@mail.gmail.com>
po 26. 5. 2025 v 10:21 odesílatel Christoph Braun <braun3@fzi.de> napsal: > Dear Melvin, > acknowledged. > > All those points above are not relevant for "quick prototyping", which I > thought you were suggesting to use URNs for in this mailing list topic? > > Besides: > URNs are not resolvable by design. > Correct, and that is *why* they fit the “just a name” phase so well. Resolution is deferred until we know the term deserves a Cool URI. Devs can still mint different URNs for the same concept. > > So it can be *one* approach, but it shouldn’t be the *only* one. > > I never claimed it to be. I said that there is no need to use URNs instead > of URIs. > Absolutely. I’m only arguing that we **add** `urn:solid:` to the toolbox, not replace HTTP URIs. Given the power of the semantic web, for example owl:equivalentPropertyOf there is a potential upgrade path, or at least a hint I suggest starting a new thread (or change topic) to perrue different patterns in dogfooding, and leave this one for urn:solid discussion, though I greatly appreciate the feedback :) > > URIs do not have to be resolvable/dereferencable (though they should be). > Agreed, http URIs *should* be dereferencable. > This is a different discussion re "In Solid apps, let’s stop using RDF > terms that 404", and URNs cannot solve that issue. > Nicely put. Each approach by nature will have different trade-offs. > > Cheers > Christoph >
Received on Monday, 26 May 2025 09:20:39 UTC