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

Hi Pat.
Looks like we still aren’t there yet.

> On 12 Oct 2022, at 01:53, Pat McBennett <patm@inrupt.com> wrote:
> 
> Hiya Hugh,
> 
>> On Tue, Oct 11, 2022 at 1:22 PM Hugh Glaser <hugh@glasers.org> wrote:
>> Hi Pat,
>> 
>> (I’ve tried sorting out the quotation levels a bit)
>> 
>> [PMcB] Thanks!
>>  
>> 
>> I like your proposal.
>> However, I think that arguing that slash is no less efficient than hash in terms of network is just wrong.
>> 
> [PMcB] Well, just to be clear, I never said it was *no* less efficient :) ! What I was trying to say was that in the case of simply dereferencing a vocab's namespace IRI, *in that case*, it's no less efficient - i.e., in both cases, slash and hash, you'd expect to get back exactly the same full-vocab-metadata response in a single HTTP request. So if you don't want to pay any inefficiency cost, then, if possible, just dereference the vocab's namespace IRI up-front to get everything you need in one single HTTP request, and just cache it for all further term lookups. That'll give you exactly the same efficiency as using hash namespace IRI - but only if you know the namespace IRI beforehand, and can dereference it up-front.
To be clear - we are counting HTTP requests here.
A look-up of one term in slash or hash mode is one request, I think.
The situation I am looking at is the lookup of more than one term.
For hash URIs, there is one request for the first term in a vocab, and then no further requests are required, because the target document has been fetched and cached.
For slash URIs, every lookup is a new request - it has to be, because each one is a different document.

So in some use modes, slash could be hugely more costly than hash.
And I can’t see any way that hash is ever more efficient in request numbers than slash, but it can be in terms of network traffic, for big and/or sparsely-used vocabs.

That’s what I meant
Hugh
> 
> I accept indeed that it will be *less efficient* in the case of looking up a single vocab term's IRI from a slash-based vocab, since yes, you need to first dereference that single term IRI, then parse out (hopefully) a `rdfs:isDefinedBy` triple, and then you have to dereference the RDF Object value of that triple to get all the metadata for all the vocab terms. So yes indeed, in that specific case, using slash is 'less efficient' (i.e., it requires a bit more client-side processing and knowledge of the `rdfs:isDefinedBy` predicate, and it's one extra HTTP request). But it should only be one extra HTTP request per vocab (when you store/save/cache the server responses), regardless of the number of terms in each vocab - so not unreasonable I think, and only needed when you don't already know a vocab's namespace IRI up-front.
> 
>> But it is a price that may well be worth paying in general.
>> After all, I still think that systems don’t resolve vocab much once they go live.
>> 
> [PMcB] Yeah, I indeed think it is a price well worth paying (even if *just* people (in general) can have a single, simple piece of *guidance* to follow, if they so choose). In other words, I think it's vastly better (especially for newbies) than saying (in paraphrasing Sarven's position (sorry Sarven, I'll reply more thoroughly to your thoughts separately :) )) - i.e., "Well, you need to decide for yourself between slash and hash for your new vocab, by weighing up: your specific use case; reflecting on empirical evidence, e.g., what characteristics do the majority of the vocabs share?; and helping the URI owners when considering persistence policies". To be honest, I feel that kind of guidance is precisely what results in newbies running screaming to the hills... :)
> 
> And yes, I totally agree too that (from my experience anyway) systems don’t resolve vocabs much at all (including when they go live). But regardless of whether they do or not, I think adopting slashes (as mere guidance) helps pave the way for Linked Data clients to *be able to* more easily and efficiently choose for themselves to resolve entire-vocab metadata and/or individual-vocab-term metadata at runtime more and more in the future (e.g., to drive user interfaces from vocab metadata, to help drive dynamic queries via link traversals, etc.). Whereas just sticking with the current empirical evidence of vocabs in the wild today (i.e., hashes) can only result in limiting future choices for vocab users.
> 
> Cheers,
> 
> Pat.
>  
>

Received on Wednesday, 12 October 2022 08:44:44 UTC