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

Hi,

Talking from the perspective of providing uniprot. I must say that using 
slashes was a good idea by my predecessor Eric Jain (among the very many 
good ideas he had and executed on).

1. You can redirect a '/ting' to '/thing'
2. Ontologies can get very big and one document becomes an issue for the 
browser :)

For FALDO we went with hash and that is OK. Because that is a complete 
and not likely to be extended ontology. i.e. the cheapest possible 
hosting was a design goal and a single document stored somewhere allows 
that.

So having learned a bit over the years I would default to '/' and only 
in very odd cases go for '#'.

Regards,
Jerven

PS> yes if doing FALDO again I would go for slash.




On 10/6/22 16:10, Pat McBennett 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 
> <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 
> <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 <mailto:patm@inrupt.com>
> 
> Connect | WebID <http://pmcb55.inrupt.net/profile/card#me>, GitHub 
> <https://github.com/pmcb55>
> 
> Explore  | www.inrupt.com <http://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.

Received on Thursday, 6 October 2022 14:23:50 UTC