Re: (Lost in the noise perhaps - so asking again) - Is a trailing slash 'better' than a trailing hash for vocabs namespace IRIs?

Hi Pat,

For one thing, hash URIs are easier to cache because there is only one
document URL. After the initial HTTP request the whole document can be
cached with its URL as the key. All following term lookups (whose URIs
start with that URL) will hit the cached document.
Slash URIs will require an initial HTTP request for *each* term and will
result in a cache entry per term.

This is based on my experience with Jena's OntDocumentManager.

Martynas
atomgraph.com


On Thu, Oct 6, 2022 at 4:15 PM Pat McBennett <patm@inrupt.com> wrote:

> So (I think!) I know all the pro's and con's of using either a trailing
> slash or a trailing hash for vocab namespace IRIs. Basically it boils down
> to hashes meaning you'll always get info on all the terms in a vocabulary,
> even if you only want info for one specific term, whereas using a slash
> means I can always get just the info for any specific, individual term I
> request.
>
> Note: using slashes provides the ability to get the best of both worlds -
> i.e., small responses when explicitly asking for info on just one term, but
> if you want info for all the terms in one HTTP response, then just serve up
> that complete vocab response when the base namespace IRI itself is
> dereferenced.
>
> Here's a nice simple illustration of the basic difference:
> - Slash: QUDT's 'CurrencyUnit' term (i.e., click on '
> https://qudt.org/schema/qudt/CurrencyUnit') and you get a nice clean,
> concise, and precise set of info on just the one term you asked for -
> lovely!
>
> - Hash: DPV's 'JointDataControllers' (i.e., click on '
> https://w3id.org/dpv#JointDataControllers') and you get bombarded with a
> huge document, with a daunting Table of Contents on the left, and info on
> hundreds of other terms that I didn't ask for, and so had no interest in
> whatsoever (don't get me wrong - this is fantastically detailed and
> potentially very useful information, but it's simply not what I asked for!).
>
> So based on the greater flexibility and future-proofing of using slash
> (i.e., it offers the best of both worlds, whereas hash is forever limited),
> I've become firmly of the opinion that slashes are just 'better' that
> hashes, and in fact are simply 'more correct' (i.e., all IRIs should be
> uniquely dereferencable).
>
> I also think the distinction is critically important when creating
> vocabularies intended for widespread and long-lasting use (such as the DPV
> vocab above). For throw-away or pet projects, sure, it doesn't really
> matter (yet even then, I still think slashes are the 'more correct' option).
>
> I know that the convention from the W3C has tended to be to use hashes,
> but I think in hindsight that was a mistake, and that the advice from the
> Semantic Web community as a whole should now be to adopt slashes
> consistently for all new vocabularies. (And it's not like using slash has
> no precedent - major 'authoritative' vocabs like QUDT, Schema.org, gist,
> SOSA, SSN, (even the venerable FOAF!) all use slash).
>
> I'd love to hear this group's thoughts. (For reference, I did ask the gist
> community if they recorded their discussions around their decision (in
> 2019) to formally switch gist from hash to slash (here
> <https://github.com/semanticarts/gist/issues/725>), but it seems they
> weren't recorded, and I've also raised the issue with the DPV group
> directly too (here <https://github.com/w3c/dpv/issues/53>)).
>
> Cheers,
>
> Pat.
>
> *Pat McBennett*, Technical Architect
>
> Contact  | patm@inrupt.com
>
> Connect | WebID <http://pmcb55.inrupt.net/profile/card#me>, GitHub
> <https://github.com/pmcb55>
>
> Explore  | www.inrupt.com
>
>
>
> This e-mail, and any attachments thereto, is intended only for use by the
> addressee(s) named herein and may contain legally privileged, confidential
> and/or proprietary information. If you are not the intended recipient of
> this e-mail (or the person responsible for delivering this document to the
> intended recipient), please do not disseminate, distribute, print or copy
> this e-mail, or any attachment thereto. If you have received this e-mail in
> error, please respond to the individual sending the message, and
> permanently delete the email.