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

Hiya Christian,

Thanks so much for engaging in this conversation - all this input is super
helpful for me!

On Mon, Oct 10, 2022 at 1:29 PM Christian Chiarcos <
christian.chiarcos@web.de> wrote:

> Dear all,
>
> maybe I'm overlooking something, but shouldn't that choice be driven by
> the intended use case?
>

[PMcB] Well, as I stated in my response to Pierre-Antoine, I consider it a
fundamental principle of Linked Data that you can never fully know the
'intended use case' for any shared vocabulary - as literally anyone should
be able to reuse that vocab, even within the confines of a closed
Enterprise (e.g., via mergers or acquisitions in the future).


>
>
Of course, defaulting to slash URIs can minimize traffic and facilitate
> retrieval under certain circumstances, but for any situation that requires
> either search or inference over the vocabulary, you need it as a whole (by
> default).
>

[PMcB] Yep, those search and inferencing concerns certainly offer
an interesting perspective! But in my opinion those requirements are
satisfied (and in fact, satisfied 'more correctly') by clients
dereferencing the vocab namespace itself (and thereby explicitly asking
for, and expecting back in response (as per a Best Practice guidance), the
"large" representation of the entire vocabulary), and not by dereferencing
individual vocab terms.

(Having said that, any 'intelligent' client *could* also choose to
follow-its-nose from dereferencing any individual term too, assuming the
vocab also follows the other Best Practice of providing `rdfs:isDefinedBy`
triples per term. But yes, for sure, that requires more work (i.e., more
'intelligence') from the client - so yeah, the simple general guidance (for
both dumb and smart clients) would simply be dereference the vocab
namespace IRI to get 'everything' in one go).



>
> If a vocabulary provider relies massively on OWL2 inferences to
> pre-populate the ontology with, say, static values for properties of
> individuals of a particular type, then these will not be found (or need to
> be explicitly searched for) if only the local URI and its immediate context
> is returned. In other words, defaulting to shlashes might be a possible
> strategy for ontologies *only if they don't make use of implicit triples*.
>

[PMcB] I might be missing something here, but would simply dereferencing
the vocab namespace IRI not solve this issue? In other words, if this
community came to agreement on the Best Practices of [use-slashes +
provide-`rdfs:isDefinedBy`-triple-per-term +
dereferencing-vocab-namespace-IRI-gives-full-vocab-metadata], then vocabs
that followed that Best Practice wouldn't have any problem here - client's
could just dereference the namespace IRI and get everything they need in a
single server repsonse, right?


>
> The case for search is similar. If a use case involves traversing, say,
> the rdf:type/rdfs:subClassOf axes, this will only be tractable if every
> vocabulary item points to the full document, e.g., by using
> rdfs:isDefinedBy at every concept. That might be considered a best
> practice, but more frequently than not it isn't observed.
>

[PMcB] Yeah, I agree that `rdfs:isDefinedBy` has frequently been omitted -
but I'd argue that that's simply due to the historic practice of
inexperienced vocab creators cut-and-pasting from what they find on the
web. I think it is telling that major, successful vocabs do indeed provide
this metadata, and for me, it's use just reflects 'good data modelling'
practice.

The whole point of me bringing up this discussion was really to see if this
community can begin to come to a consensus on vocabulary Best Practices
across the board.  I thought Slash vs Hash might be a good starting point,
but it has kinda expanded into this `rdfs:isDefinedBy` issue too (which is
totally fine I think - all part of my learning anyways :) !).


> And that's for a reason: It adds linear growth in comparison to the
> underlying data. Not extreme, but still, that can amount to quite some
> overhead.
>

[PMcB] I really, really don't think linear growth is the reason for vocabs
often omitting `rdfs:isDefinedBy` triples. Sure, it's a subjective opinion
of course, but I really do think the reason is simply that vocab creators
have been unaware of the term, or unaware of its benefits (often because
newbies just think narrowly of a vocab satisfying their immediate needs (as
all developers tend to do), without thinking of the bigger picture of,
"What could some user on the other side of the planet possibly want/need
from this vocabulary I'm publishing and sharing with the
world/or-rest-of-my-Enterprise?".

We're only talking about T-Box (i.e., schema metadata) triples here, and
not A-Box (or instance) data - so I really think the extra triples are a
very minor extra cost in the grand scheme of things, and that 'good data
modelling' and supporting potential future use's of my vocab (e.g.,
allowing any potential user to follow-their-nose from a single term to the
overall vocab) is well, well worth it.

(And again, this would just be a community stated preference, a guidance.
Nobody can force any vocab creator to include these `rdfs:isDefinedBy`
triples - so if you don't want to, or can't for some reason, then don't.
But I think it would be genuinely useful for vocab creators to simply be
more fully aware of the consequences of their going against this
preference/guidance/Best Practice - that's all!).


>
> As for newbies, I guess *one* naive strategy to familiarize yourself with
> a vocabulary and RDF technology in general is to copy and paste URIs from
> their vocabularies to an ontology browser, say, Protégé. If that resolves
> to a full and well-structured view on the overall vocabulary they'll
> probably be happier than if it just gives them a single concept (or, if the
> search term doesn't lead to a class definition, *nothing*). For that
> reason, I'd prefer to remain with hashes as default.
>

[PMcB] Well, for that example of cutting-and-pasting a vocab term IRI into
Protege (or any other RDF-aware tool), I'd suggest that the 'more correct'
thing to do there would be for the tool to help the user along, since
jumping to assumptions about what the user might actually want is never a
good practice generally. For instance, the tool could de-reference the
pasted-in IRI and inspect the response - if it was just a single term's
metadata with an `rdfs:isDefinedBy` triple, then the tool could pop up a
nice helpful dialog box explaining that that IRI was a term from a vocab,
and asking the user if they'd like to follow the reference to the entire
vocab, and if they do, then dereference that too. (It wouldn't have to be
an intrusive model dialog box of course, it could also just be a checkbox
beside the textbox you paste the IRI into too - i.e., "Tick here if you
want Protege to also pull in the full vocab metadata too").

Again, I think this is actually a really nice example of where slashes are
clearly 'better' - i.e., they are the only approach that allows tools to
offer clients a choice in what they *actually* might want to do - i.e., "Do
you really just want info on that IRI you provided me, or would you prefer
I *also* fetch all the info for the entire vocab that defines this
term...?".

As multiple people have stated, there really are multiple *potential*
use-cases (and this is regardless of whether the vocab creator might have
literally only one, extremely narrow use-case in mind originally - i.e.,
once it's published anywhere, once it's shared, it's available for anyone
else with access to it (over the entire Web, or within an Enterprise) to
use it however *they* see fit). So no-one can possibly know a-priori what
all those possible, potential use-cases might be, now or in the future - so
why would anyone choose to constrain user choices (which is what using
hashes clearly does today - i.e., "You're only ever going to be able to get
back all the vocab metadata, whether that's actually what you want or not -
sorry about that!").



> Slash URIs are preferrable under certain use cases, and especially for
> expert users, but using them as a default might increase the entry barrier
> to both vocabularies and the technology overall.
>

[PMcB] But to summarise again - no vocab publisher can ever know the
potential use-cases for their vocab, so offering the most flexibility
(i.e., slashes) just seems like good netizen-ship(!) to me, and so
therefore 'better' guidance in general (and again, it's just guidance - use
hashes if you want, but just know and recognize that you are limiting the
choices of your users. Perhaps that's perfectly valid, and you expressly
want to limit their choices, forever - if so, then go ahead and do that).

But it's also important to understand that using slashes doesn't *require*
extra work, it's only needed if the hosting server *chooses* to provide the
extra flexibility to clients.

And finally, (kinda reiterating the 'multiple use-case' argument) I think
it would be a mistake for any vocab to always assume that returning the
entire vocab info (i.e., using a hash) necessarily provides a lower-barrier
to entry. I think the example of QUDT's CurrencyUnit is a great one - for a
user who *just* wants to now what that single term means, I think the
webpage that that user gets today is clear, unambiguous, uncluttered, and
presents a very low barrier to just understanding what that *one term*
means - i.e., maybe they specifically want to see it in clear, simple
isolation: https://qudt.org/schema/qudt/CurrencyUnit.

Yes, *perhaps* providing surrounding context for that term *might* be even
more useful for some users too - but that's making a huge assumption. It
could just as validly be argued that automatically providing all that extra
context is significantly *raising* the barrier to entry for some users -
i.e., they might feel bombarded with information overload, for example if
all they want is to understand what is a 'JointDataController', but DPV,
for example, provides all this 'surrounding noise' too: '
https://w3id.org/dpv#JointDataControllers'.

And I think that same argument applies to search, or inferencing, or vocab
editing tools, or visualization tools, or any tooling, or any applications
- some use-cases may want just single vocab term info, some use-cases may
want all vocab info, and some use-cases will want both at different times.
Only slashes allow vocab users the opportunity, or the possibility, to
choose for themselves...


>
> Best,
> Christian
>
>
>
> Am Mo., 10. Okt. 2022 um 12:27 Uhr schrieb Pierre-Antoine Champin <
> pierre-antoine@w3.org>:
>
>> Dear Pat,
>>
>> I just wanted to make sure we were on the same page regarding the "best
>> of both worlds" situation, but clearly we are.
>>
>> To answer your question about my points c) and d) below:
>> when the client retrieves something from http://ex.co/x/, it contains
>> some triples about http://ex.co/x/Z. But when the client wants to know
>> exactly what http://ex.co/x/Z is, how does it determine that it does *not
>> need *to retrieve http://ex.co/x/Z, because it already retrieved
>> everything there is to know about http://ex.co/x/Z when it retrieved
>> http://ex.co/x/ ?
>>
>> One way to achieve this would be to include, in the content of
>> http://ex.co/x/, the triple
>>     <http://ex.co/x/Z> <http://ex.co/x/Z> rdfs:isDefinedBy
>> <http://ex.co/x/> <http://ex.co/x/>.
>>
>> but again, that is a convention that both the server and the client have
>> to share.
>>
>>
>> Overall, I think we agree that slash-IRIs provide more flexibility.
>> However,
>>
>> - that flexibility requires more work on the server side (to maintain
>> consistency between the "focused" representations and the "large"
>> representation), and
>> - it only pays off if the client is smart enough to understand the hints
>> provided by the server (otherwise, the dumb client may only retrieve the
>> "focused" representations -- or worse, retrieve all the "focused"
>> representations AND the "large" representation).
>>
>> > But all I'm looking for here is this community's opinion on whether we
>> can offer a clear, *single*, *preference* for the creators of new RDF
>> vocabularies going forward
>>
>> Again, I believe this is a matter of trade-of, so my personal opinion is:
>> no, there is no clear single solution that is better than the other in all
>> cases.
>>
>> > Newbies don't want to have to 'decide for themselves' if they can help
>> it when learning new technology - and so they'll just continue the current
>> practice of cutting-and-pasting what they see as most prevalent out there
>> today [i.e. hash-IRIs]
>>
>> ... and I personally believe this is an OK approach for newbies. Whenever
>> your ontology becomes too big for this approach (as Schema.org or QUDT),
>> and/or you look for more flexibility, you need more expertise -- and then
>> you need to make informed choices. :)
>>
>>   pa
>> On 10/10/2022 11:08, Pat McBennett wrote:
>>
>> Hi Pierre-Antoine,
>>
>> Thanks so much for engaging in the discussion - I really, really
>> appreciate it! (I'm re-sending this as I just noticed that the tabbing from
>> my GMail response didn't come through formatted correctly - so I've
>> prefixed quotes with initials of [PAC] for [Pierre-Antonie Champin])
>>
>> You bring up some great points, but in my view, and with a bit more
>> clarification from my side, I think they all seem to actually be
>> reinforcing the argument for slashes (just as a *preference* when creating
>> new vocabs)!
>>
>> [PAC] "In the general case, when you encounter an IRI of the form
>> http://ex.co/x/Y, you can not assume that http://ex.co/x/ will contain
>> the definition of http://ex.co/x/Y together with other related terms."
>>
>> Yep, absolutely, I totally agree - this is the wild-wild-west of the
>> World Wide Web after all, so yeah, regardless of slashes or hashes, we can
>> never assume anything at all when dereferencing any IRI anywhere.
>> And so yeah, nobody should ever make the assumption you point out here
>> (it never even occurred to me that anyone would!). As you say below, that's
>> why `rdfs:isDefinedBy` is so useful (and should be a general Best Practice
>> for vocabs anyway, I'd say).
>>
>> [PAC] "For this you need,
>>
>> a) the server to provide an affordance in the description of
>> http://ex.co/x/Y pointing to http://ex.co/x/  (e.g. by using
>> rdfs:isDefinedBy)
>>
>> Yep - totally agree. Which is why I always highly recommend (as a
>> separate, but related, general Best Practice) that all vocab terms should
>> always provide an `rdfs:isDefinedBy` triple regardless. (Thankfully that
>> term's local name (i.e., 'isDefinedBy') is very intuitively
>> self-explanatory!)
>>
>> b) the client to understand and follow that affordance."
>>
>> Well, yeah, kinda, but only *if* that client *wants* to be able to take
>> advantage of that extremely handy and helpful little affordance to
>> follow-its-nose. And given the client needs to understand RDF (to some
>> minimal degree at least) in the first place to be working with RDF vocabs
>> at all, that doesn't seem like a problem to me, or any kind of an issue at
>> all.
>>
>> In other words, all I'm stating is that if we *prefered* slashes, then
>> any client wishing to understand what any individual IRI *is* can simply
>> deference that IRI (i.e., isn't that just the first principle of Linked
>> Data really!). And they should always (in my opinion) be able to expect to
>> get back *only* a representation of whatever that IRI represents. So *if*
>> the IRI they dereferenced happened to be an individual vocab term, then
>> (only with slash-based vocabs) they'd correctly get back data on just that
>> one vocab term.
>>
>> (I'd consider it merely a Best Practice that they might *also* be able to
>> expect a `rdfs:isDefinedBy` link to the overall vocab within which that
>> single vocab term is defined - but they only need to understand and/or
>> follow that link if they ever wanted to *also* discover information on the
>> containing is-defined-by vocab.)
>> So in other words, I only see goodness here, and a simple consistent
>> expression of Linked Data first principles (i.e., all 'things of interest'
>> should have uniquely *dereferencable* IRIs, and you can choose to
>> follow-your-nose to 'more info' if you want to, and you understand the
>> predicates leading the way).
>>
>> [PAC] "c) the description at http://ex.co/x/ to include some information
>> about any term (e.g. http://ex.co/x/Z) in contains stating "there is
>> nothing more to know about this term" (e.g. by using rdfs:isDefinedBy
>> again)"
>>
>> I don't quite follow this point - perhaps you could elaborate a little,
>> or provide some sample Turtle...? (For example, I would expect the
>> description at http://ex.co/x/ (assuming that to be a vocab namespace
>> IRI) to indeed contain *all* of the information about the vocab itself
>> (like it's versioning info, preferred prefix, creation date, etc.), and
>> *all* the information about *all* of the terms that that vocab
>> contains/defines - i.e., exactly as QUDT do today when you click on their
>> namespace IRI: https://qudt.org/schema/qudt/ (although they only seem to
>> provide Turtle, and not a content-negotiable full HTML representation that
>> I'd prefer to see them provide from my browser (e.g., DPV does provide a
>> lovely 'complete vocab' that is a content-negotiable (i.e., HTML or Turtle)
>> representation when you dereference it's namespace IRI today:
>> http://www.w3.org/ns/dpv#)).
>>
>>
>> [PAC] "d) the client to understand that statement and refrain from
>> fetching http://ex.co/x/Z later on"
>>
>> I didn't follow the above point, so this one loses me too, but (I think)
>> this comes down to clients needing to know (regardless of slash or hash)
>> the basic difference between an `owl:Ontology` and an `rdf:Class` or
>> `rdfs:Property` (i.e., between 'a full vocab' and 'a term in a vocab') in
>> the responses they get from servers when they are dereferencing
>> vocab-related IRIs anyway. I don't think the issues around caching are
>> majorly affected by the slash/hash choice - but perhaps I'm missing your
>> real point here...
>>
>>
>> [PAC] "So you don't get "the best of both world" as automatically as you
>> suggest."
>>
>> Oh yeah, absolutely - so we agree again. I should have been clearer
>> perhaps - I certainly didn't mean to imply that getting
>> the-best-of-both-worlds was in any way 'automatic' at all. As I said later
>> in my post, getting both will require more work on the server side, or from
>> tooling.
>> All I'm trying to emphasize is that slashes provide *a means* to get
>> the-best-of-both-worlds, whereas with hashes the best servers can ever
>> offer to clients (regardless of the needs or wants of those clients) is to
>> return information on all terms in the entire vocab (since, by HTTP design,
>> the server will never receive the hash fragment in any HTTP request), and
>> so you can never, ever offer any client *the option* to just retrieve a
>> single vocab term's information and nothing else *if that's what the client
>> wants/needs/prefers*.
>>
>> [PAC] "Terms of a vocabulary/ontology rarely make sense in isolation. So
>> arguably, serving the entire vocabulary provides you with enough context to
>> understand/use the term appropriately."
>>
>> Well, I wouldn't agree with that at all. I think QUDT's CurrencyUnit (
>> https://qudt.org/schema/qudt/CurrencyUnit) is a great example of where
>> it makes perfect sense (i.e., all I want to know is what QUDT *mean* by a
>> 'CurrencyUnit'). And surely no-one would argue that Schema.org should
>> switch from its current slash to use hash instead, because terms like
>> Person (https://schema.org/Person) need context from the entire 2,500
>> terms defined in Schema.org as a whole.
>>
>> But I do certainly agree with your point that individual terms should
>> indeed provide enough context to understand/use the term - but I think all
>> that context should be provided *in isolation* within the vocab's
>> definition of that term itself, and should certainly not require
>> downloading the entire vocabulary - i.e., examples of precisely that are
>> `rdfs:isDefinedBy`, `rdfs:domain`, `schema:rangeIncludes`, `rdfs:seeAlso`,
>> `skos:related`, `skos:narrower`, etc.
>> Now, given that much of that 'term-specific context' would actually be
>> IRIs, it should then be up to the client to decide if it now wishes to
>> dereference each of those individual links with multiple HTTP requests, or
>> if it actually wishes to now download the entire vocabulary in one HTTP
>> request (again, only slashes offer all clients the choice and flexibility
>> for them to decide between those options for themselves).
>>
>> [PAC] "And then you get "bombarded with a huge document"..."
>>
>> Yep, but again my point is that only with slash do clients get at least
>> the option, or the ability, or the possibility, to *choose for themselves*
>> whether they get bombarded with the entire vocab in one HTTP request or not.
>>
>>
>> [PAC] "[PMcB] - So doesn't that demonstrate my whole point - i..e, that
>> with slashes I can get the best of both worlds
>>
>> I don't think so. They are different trade-offs between providing
>> targeted content vs. reducing the number of HTTP queries, and between
>> working with dumb clients and/or dumb servers vs. requiring more
>> coordination between them  (e.g. providing and following rdfs:isDefinedBy
>> links)."
>>
>> Well to emphasize my point, with slashes I *can* get
>> the-best-of-both-worlds, with hashes I *can't*.
>> Yep, for sure there are tradeoffs, and indeed implementing the full set
>> of options (with full conneg, and providing/generating individual
>> term-specific static HTML pages, etc.) definitely requires more server-side
>> work/tooling. But I'd argue that adopting slash still doesn't *require*
>> that any of that work be done at all, for example, if all you have to work
>> with are dumb servers - i.e. your dumb server can just continue as always,
>> serving up the full vocab information for all requests using the exact same
>> single static page it uses today with hash, by simply using a single URL
>> rewrite rule to rewrite http://ex.co/x/Z to http://ex.co/x#Z
>> <http://ex.co/x/Z>. Sure, that breaks the client expectation somewhat
>> (i.e., "I only asked for info on term Z, and you gave me info on all the
>> vocab terms - but at least you provided the HTML anchor so that my browser
>> jumped down automatically to the info for term Z!") - but that's a
>> worst-case scenario (i.e., a scenario that may have been forced on you due
>> to only having dumb servers and no server-side tooling), and yet it's still
>> no worse than what you get today with hashes (i.e., it *is* what you get
>> today with hashes).
>>
>> [PAC] "[PMcB} - And that's why I posit that slashes are simply 'more
>> correct' (i.e., since *only* slashes can ever allow servers to always know
>> exactly, unambiguously, what a requesting client is really looking for
>>
>> I don't by that. The server can never know exactly nor unambiguously what
>> the intent of the client is, nor should it (separation of concerns)."
>>
>> Sure, of course :) ! So let me re-phrase my point - only slashes provide
>> the means for the server to *see* the *full/complete IRI* that a client may
>> wish to de-reference. In other words, with hashes, by HTTP design, the
>> client *must* strip off the hash fragment (if any) before putting the HTTP
>> request on the wire - hence the server can't ever distinguish between a
>> client asking for info on a single term (e.g., GET http://ex.co/x#Z
>> <http://ex.co/x/Z>) or a client wishing for info on the entire vocab
>> (e.g., GET http://ex.co/x# <http://ex.co/x/Z> or just GET http://ex.co/x
>> <http://ex.co/x/Z>).
>>
>>
>> [PAC] "Cant' help but cite the priority of consituencies remininded in
>> https://www.w3.org/TR/design-principles/#priority-of-constituencies"
>>
>> Yep, exactly (we agree again!) - but for me, this is precisely an
>> argument for slashes - i.e., hashes restrict what clients can possibly get
>> back from a server (i.e., they'll always get the full vocab information
>> back), whereas slashes at least provide *the potential* for servers to
>> offer clients more flexibility and choice (i.e., info just on individual
>> terms, *or* info on the full vocab).
>> So surely giving clients *more* choice (with slashes), not less (with
>> hashes), is putting their needs first (since we can't possibly ever know
>> up-front, for any vocab, the 'needs' of all potential users (i.e., the
>> entire user base of the Web) for vocabs we publish, right!?
>>
>> [PAC] "Also, in a distributed setting such as the web, you can not assume
>> that all other parties will always do the right thing™."
>>
>> Again, I totally agree (who wouldn't!).
>> But all I'm looking for here is this community's opinion on whether we
>> can offer a clear, *single*, *preference* for the creators of new RDF
>> vocabularies going forward. I think we can, and that *preference* should be
>> using slashes (i.e., not a requirement, or a mandate, or something anyone
>> can ever force people to do). I just think the current state of guidance in
>> the Linked Data community is too loose and therefore off-putting for
>> newbies - i.e., "You can do either, there are pro's and con's, but it
>> doesn't really matter much, so you can just decide for yourself". Newbies
>> don't want to have to 'decide for themselves' if they can help it when
>> learning new technology - and so they'll just continue the current practice
>> of cutting-and-pasting what they see as most prevalent out there today
>> (e.g., nearly all the W3C vocab examples today), which will most likely
>> mean repeating the 'mistake' of using hashes, and thereby 'hurting' the
>> longer-term options for client/user software that may wish to have the
>> ability (at some future stage perhaps) to be able to choose for themselves
>> between term-specific or full-vocab lookups.
>>
>> Thanks again Pierre-Antoine for pushing me to think this through even
>> more thoroughly - I hope it's been somewhat useful for you (and others?) to
>> ponder on too :)
>>
>> 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
>>
>>
>>
>>
>> On Sat, Oct 8, 2022 at 2:10 AM Pat McBennett <patm@inrupt.com> wrote:
>>
>>> Hi Pierre-Antoine,
>>>
>>> Thanks so much for engaging in the discussion - I really, really
>>> appreciate it!
>>>
>>> You bring up some great points, but in my view, and with a bit more
>>> clarification from my side, I think they all seem to actually be
>>> reinforcing the argument for slashes (just as a *preference* when creating
>>> new vocabs)!
>>>
>>> In the general case, when you encounter an IRI of the form
>>> http://ex.co/x/Y, you can not assume that http://ex.co/x/ will contain
>>> the definition of http://ex.co/x/Y together with other related terms.
>>>
>>> Yep, absolutely, I totally agree - this is the wild-wild-west of the
>>> World Wide Web after all, so yeah, regardless of slashes or hashes, we can
>>> never assume anything at all when dereferencing any IRI anywhere.
>>> And so yeah, nobody should ever make the assumption you point out here
>>> (it never even occurred to me that anyone would!). As you say below, that's
>>> why `rdfs:isDefinedBy` is so useful (and should be a general Best Practice
>>> for vocabs anyway, I'd say).
>>>
>>> For this you need,
>>>
>>> a) the server to provide an affordance in the description of
>>> http://ex.co/x/Y pointing to http://ex.co/x/  (e.g. by using
>>> rdfs:isDefinedBy)
>>>
>>> Yep - totally agree. Which is why I always highly recommend (as a
>>> separate, but related, general Best Practice) that all vocab terms should
>>> always provide an `rdfs:isDefinedBy` triple regardless. (Thankfully that
>>> term's local name (i.e., 'isDefinedBy') is very intuitively
>>> self-explanatory!)
>>>
>>> b) the client to understand and follow that affordance.
>>>
>>> Well, yeah, kinda, but only *if* that client *wants* to be able to take
>>> advantage of that extremely handy and helpful little affordance to
>>> follow-its-nose. And given the client needs to understand RDF (to some
>>> minimal degree at least) in the first place to be working with RDF vocabs
>>> at all, that doesn't seem like a problem to me, or any kind of an issue at
>>> all.
>>>
>>> In other words, all I'm stating is that if we *prefered* slashes, then
>>> any client wishing to understand what any individual IRI *is* can simply
>>> deference that IRI (i.e., isn't that just the first principle of Linked
>>> Data really!). And they should always (in my opinion) be able to expect to
>>> get back *only* a representation of whatever that IRI represents. So *if*
>>> the IRI they dereferenced happened to be an individual vocab term, then
>>> (only with slash-based vocabs) they'd correctly get back data on just that
>>> one vocab term.
>>>
>>> (I'd consider it merely a Best Practice that they might *also* be able
>>> to expect a `rdfs:isDefinedBy` link to the overall vocab within which that
>>> single vocab term is defined - but they only need to understand and/or
>>> follow that link if they ever wanted to *also* discover information on the
>>> containing is-defined-by vocab.)
>>> So in other words, I only see goodness here, and a simple consistent
>>> expression of Linked Data first principles (i.e., all 'things of interest'
>>> should have uniquely *dereferencable* IRIs, and you can choose to
>>> follow-your-nose to 'more info' if you want to, and you understand the
>>> predicates leading the way).
>>>
>>> c) the description at http://ex.co/x/ to include some information about
>>> any term (e.g. http://ex.co/x/Z) in contains stating "there is nothing
>>> more to know about this term" (e.g. by using rdfs:isDefinedBy again)
>>>
>>> I don't quite follow this point - perhaps you could elaborate a little,
>>> or provide some sample Turtle...? (For example, I would expect the
>>> description at http://ex.co/x/ (assuming that to be a vocab namespace
>>> IRI) to indeed contain *all* of the information about the vocab itself
>>> (like it's versioning info, preferred prefix, creation date, etc.), and
>>> *all* the information about *all* of the terms that that vocab
>>> contains/defines - i.e., exactly as QUDT do today when you click on their
>>> namespace IRI: https://qudt.org/schema/qudt/ (although they only seem
>>> to provide Turtle, and not a content-negotiable full HTML representation
>>> that I'd prefer to see them provide from my browser (e.g., DPV does provide
>>> a lovely 'complete vocab' that is a content-negotiable (i.e., HTML or
>>> Turtle) representation when you dereference it's namespace IRI today:
>>> http://www.w3.org/ns/dpv#)).
>>>
>>>
>>> d) the client to understand that statement and refrain from fetching
>>> http://ex.co/x/Z later on
>>>
>>> I didn't follow the above point, so this one loses me too, but (I think)
>>> this comes down to clients needing to know (regardless of slash or hash)
>>> the basic difference between an `owl:Ontology` and an `rdf:Class` or
>>> `rdfs:Property` (i.e., between 'a full vocab' and 'a term in a vocab') in
>>> the responses they get from servers when they are dereferencing
>>> vocab-related IRIs anyway. I don't think the issues around caching are
>>> majorly affected by the slash/hash choice - but perhaps I'm missing your
>>> real point here...
>>>
>>>
>>> So you don't get "the best of both world" as automatically as you
>>> suggest.
>>>
>>> Oh yeah, absolutely - so we agree again. I should have been clearer
>>> perhaps - I certainly didn't mean to imply that getting
>>> the-best-of-both-worlds was in any way 'automatic' at all. As I said later
>>> in my post, getting both will require more work on the server side, or from
>>> tooling.
>>> All I'm trying to emphasize is that slashes provide *a means* to get
>>> the-best-of-both-worlds, whereas with hashes the best servers can ever
>>> offer to clients (regardless of the needs or wants of those clients) is to
>>> return information on all terms in the entire vocab (since, by HTTP design,
>>> the server will never receive the hash fragment in any HTTP request), and
>>> so you can never, ever offer any client *the option* to just retrieve a
>>> single vocab term's information and nothing else *if that's what the client
>>> wants/needs/prefers*.
>>>
>>> Terms of a vocabulary/ontology rarely make sense in isolation. So
>>> arguably, serving the entire vocabulary provides you with enough context to
>>> understand/use the term appropriately.
>>>
>>> Well, I wouldn't agree with that at all. I think QUDT's CurrencyUnit (
>>> https://qudt.org/schema/qudt/CurrencyUnit) is a great example of where
>>> it makes perfect sense (i.e., all I want to know is what QUDT *mean* by a
>>> 'CurrencyUnit'). And surely no-one would argue that Schema.org should
>>> switch from its current slash to use hash instead, because terms like
>>> Person (https://schema.org/Person) need context from the entire 2,500
>>> terms defined in Schema.org as a whole.
>>>
>>> But I do certainly agree with your point that individual terms should
>>> indeed provide enough context to understand/use the term - but I think all
>>> that context should be provided *in isolation* within the vocab's
>>> definition of that term itself, and should certainly not require
>>> downloading the entire vocabulary - i.e., examples of precisely that are
>>> `rdfs:isDefinedBy`, `rdfs:domain`, `schema:rangeIncludes`, `rdfs:seeAlso`,
>>> `skos:related`, `skos:narrower`, etc.
>>> Now, given that much of that 'term-specific context' would actually be
>>> IRIs, it should then be up to the client to decide if it now wishes to
>>> dereference each of those individual links with multiple HTTP requests, or
>>> if it actually wishes to now download the entire vocabulary in one HTTP
>>> request (again, only slashes offer all clients the choice and flexibility
>>> for them to decide between those options for themselves).
>>>
>>> And then you get "bombarded with a huge document"...
>>>
>>> Yep, but again my point is that only with slash do clients get at least
>>> the option, or the ability, or the possibility, to *choose for themselves*
>>> whether they get bombarded with the entire vocab in one HTTP request or not.
>>>
>>>
>>> So doesn't that demonstrate my whole point - i..e, that with slashes I
>>> can get the best of both worlds
>>>
>>> I don't think so. They are different trade-offs between providing
>>> targeted content vs. reducing the number of HTTP queries, and between
>>> working with dumb clients and/or dumb servers vs. requiring more
>>> coordination between them  (e.g. providing and following rdfs:isDefinedBy
>>> links).
>>>
>>> Well to emphasize my point, with slashes I *can* get
>>> the-best-of-both-worlds, with hashes I *can't*.
>>> Yep, for sure there are tradeoffs, and indeed implementing the full set
>>> of options (with full conneg, and providing/generating individual
>>> term-specific static HTML pages, etc.) definitely requires more server-side
>>> work/tooling. But I'd argue that adopting slash still doesn't *require*
>>> that any of that work be done at all, for example, if all you have to work
>>> with are dumb servers - i.e. your dumb server can just continue as always,
>>> serving up the full vocab information for all requests using the exact same
>>> single static page it uses today with hash, by simply using a single URL
>>> rewrite rule to rewrite http://ex.co/x/Z to http://ex.co/x#Z
>>> <http://ex.co/x/Z>. Sure, that breaks the client expectation somewhat
>>> (i.e., "I only asked for info on term Z, and you gave me info on all the
>>> vocab terms - but at least you provided the HTML anchor so that my browser
>>> jumped down automatically to the info for term Z!") - but that's a
>>> worst-case scenario (i.e., a scenario that may have been forced on you due
>>> to only having dumb servers and no server-side tooling), and yet it's still
>>> no worse than what you get today with hashes (i.e., it *is* what you get
>>> today with hashes).
>>>
>>> And that's why I posit that slashes are simply 'more correct' (i.e.,
>>> since *only* slashes can ever allow servers to always know exactly,
>>> unambiguously, what a requesting client is really looking for
>>>
>>> I don't by that. The server can never know exactly nor unambiguously
>>> what the intent of the client is, nor should it (separation of concerns).
>>>
>>> Sure, of course :) ! So let me re-phrase my point - only slashes provide
>>> the means for the server to *see* the *full/complete IRI* that a client may
>>> wish to de-reference. In other words, with hashes, by HTTP design, the
>>> client *must* strip off the hash fragment (if any) before putting the HTTP
>>> request on the wire - hence the server can't ever distinguish between a
>>> client asking for info on a single term (e.g., GET http://ex.co/x#Z
>>> <http://ex.co/x/Z>) or a client wishing for info on the entire vocab
>>> (e.g., GET http://ex.co/x# <http://ex.co/x/Z> or just GET http://ex.co/x
>>> <http://ex.co/x/Z>).
>>>
>>>
>>> Cant' help but cite the priority of consituencies remininded in
>>> https://www.w3.org/TR/design-principles/#priority-of-constituencies
>>>
>>> Yep, exactly (we agree again!) - but for me, this is precisely an
>>> argument for slashes - i.e., hashes restrict what clients can possibly get
>>> back from a server (i.e., they'll always get the full vocab information
>>> back), whereas slashes at least provide *the potential* for servers to
>>> offer clients more flexibility and choice (i.e., info just on individual
>>> terms, *or* info on the full vocab).
>>> So surely giving clients *more* choice (with slashes), not less (with
>>> hashes), is putting their needs first (since we can't possibly ever know
>>> up-front, for any vocab, the 'needs' of all potential users (i.e., the
>>> entire user base of the Web) for vocabs we publish, right!?
>>>
>>> Also, in a distributed setting such as the web, you can not assume that
>>> all other parties will always do the right thing™.
>>>
>>> Again, I totally agree (who wouldn't!).
>>> But all I'm looking for here is this community's opinion on whether we
>>> can offer a clear, *single*, *preference* for the creators of new RDF
>>> vocabularies going forward. I think we can, and that *preference* should be
>>> using slashes (i.e., not a requirement, or a mandate, or something anyone
>>> can ever force people to do). I just think the current state of guidance in
>>> the Linked Data community is too loose and therefore off-putting for
>>> newbies - i.e., "You can do either, there are pro's and con's, but it
>>> doesn't really matter much, so you can just decide for yourself". Newbies
>>> don't want to have to 'decide for themselves' if they can help it when
>>> learning new technology - and so they'll just continue the current practice
>>> of cutting-and-pasting what they see as most prevalent out there today
>>> (e.g., nearly all the W3C vocab examples today), which will most likely
>>> mean repeating the 'mistake' of using hashes, and thereby 'hurting' the
>>> longer-term options for client/user software that may wish to have the
>>> ability (at some future stage perhaps) to be able to choose for themselves
>>> between term-specific or full-vocab lookups.
>>>
>>> Thanks again Pierre-Antoine for pushing me to think this through even
>>> more thoroughly - I hope it's been somewhat useful for you (and others?) to
>>> ponder on too :)
>>>
>>> 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
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Oct 7, 2022 at 8:07 AM Pierre-Antoine Champin <
>>> pierre-antoine@w3.org> wrote:
>>>
>>>> On 07/10/2022 01:49, Pat McBennett wrote:
>>>>
>>>> Hi Martynas,
>>>>
>>>> Thanks for the feedback!
>>>>
>>>> But I think any vocabulary can just as easily support that same caching
>>>> benefit with slash-based vocab namespace IRIs too, *without* having
>>>> to require an initial HTTP request for *each* term - i.e., by simply
>>>> returning the entire vocab on namespace IRI lookups.
>>>>
>>>> In the general case, when you encounter an IRI of the form
>>>> http://ex.co/x/Y, you can not assume that http://ex.co/x/ will contain
>>>> the definition of http://ex.co/x/Y together with other related terms.
>>>> For this you need,
>>>>
>>>> a) the server to provide an affordance in the description of
>>>> http://ex.co/x/Y pointing to http://ex.co/x/
>>>> b) the client to understand and follow that affordance (e.g. by using
>>>> rdfs:isDefinedBy)
>>>> c) the description at http://ex.co/x/ to include some information
>>>> about any term (e.g. http://ex.co/x/Z) in contains stating "there is
>>>> nothing more to know about this term" (e.g. by using rdfs:isDefinedBy again)
>>>> d) the client to understand that statement and refrain from fetching
>>>> http://ex.co/x/Z later on
>>>>
>>>> So you don't get "the best of both world" as automatically as you
>>>> suggest.
>>>>
>>>>
>>>> I think QUDT is a really nice, simple example that very easily
>>>> demonstrates exactly this today. It has a slash namespace IRI, and if I
>>>> only ever request info on individual single vocab terms (e.g., try clicking
>>>> now on `https://qudt.org/schema/qudt/CurrencyUnit`) then yes, I'd
>>>> encounter that 'HTTP request per lookup' you suggest (but I'd be getting
>>>> precisely what I asked for each time!).
>>>>
>>>> Terms of a vocabulary/ontology rarely make sense in isolation. So
>>>> arguably, serving the entire vocabulary provides you with enough context to
>>>> understand/use the term appropriately.
>>>>
>>>>
>>>> But I can just as easily avoid that scenario today too by simply
>>>> requesting the vocab's namespace IRI instead - e.g., try it right now by
>>>> just clicking on `https://qudt.org/schema/qudt`
>>>> <https://qudt.org/schema/qudt>. See - you get back the entire vocab
>>>> containing all the vocab terms in a single HTTP response, which can be
>>>> cached and keyed on that one namespace IRI (exactly as you would if they'd
>>>> used a hash instead).
>>>>
>>>> And then you get "bombarded with a huge document", to quote one of your
>>>> arguments against hash-IRIs. Seems to me that you get the worst of both
>>>> worlds here: I had to perform two HTTP queries (one on CurrencyUnit, got
>>>> get the link to the whole vocab, and one on the vocab) instead of one (with
>>>> hash IRIs), and I still end up with a huge ontology. (yes, playing devil's
>>>> advocate here a little)
>>>>
>>>> (I'm not familiar with Jena's OntDocumentManager, but I'm sure its
>>>> caching code could easily be extended to take advantage of servers that
>>>> choose to server up slash-based vocabularies as QUDT demonstrates is so
>>>> feasible today.)
>>>> So doesn't that demonstrate my whole point - i..e, that with slashes I
>>>> can get the best of both worlds
>>>>
>>>> I don't think so. They are different trade-offs between providing
>>>> targeted content vs. reducing the number of HTTP queries, and between
>>>> working with dumb clients and/or dumb servers vs. requiring more
>>>> coordination between them  (e.g. providing and following rdfs:isDefinedBy
>>>> links).
>>>>
>>>> (i.e., precise term-specific HTTP responses if I want them, *and* the
>>>> entire vocab in a single HTTP response if I want that too)? Using a hash
>>>> completely locks me out, forever, of being able to achieve those lovely
>>>> clean term-specific responses.
>>>> And that's why I posit that slashes are simply 'more correct' (i.e.,
>>>> since *only* slashes can ever allow servers to always know exactly,
>>>> unambiguously, what a requesting client is really looking for
>>>>
>>>> I don't by that. The server can never know exactly nor unambiguously
>>>> what the intent of the client is, nor should it (separation of concerns
>>>> <https://en.wikipedia.org/wiki/Separation_of_concerns>).
>>>>
>>>> (i.e., a term-specific response, or an entire vocab response)), and it
>>>> does so without losing any of the benefits of using a hash. (I do, by the
>>>> way, totally appreciate that servers choosing to work as the QUDT servers
>>>> do today might require a bit more server-side work. But my whole point is
>>>> to ask this community which option they consider "more technically correct
>>>> today and forever", and not "which option is easier for servers or vocab
>>>> creators/hosters/editors/publishers today in the absence of any tooling
>>>> support".
>>>>
>>>> Cant' help but cite the priority of consituencies remininded in
>>>> https://www.w3.org/TR/design-principles/#priority-of-constituencies
>>>>
>>>> "User needs come before the needs of web page authors, which come
>>>> before the needs of user agent implementors, which come before the needs of
>>>> specification writers, which come before theoretical purity."
>>>>
>>>> Don't get me wrong, I get the point of thinking beyond the limitation
>>>> of current tools. That's a valuable exercise. But practicality does also
>>>> matter.
>>>>
>>>> Also, in a distributed setting such as the web, you can not assume that
>>>> all other parties will always do the right thing™.
>>>>
>>>>   my 2€
>>>>
>>>>   pa
>>>>
>>>> In other words, I think that QUDT-server-like behaviour can be provided
>>>> easily by tooling, which I'd personally be very happy to work on
>>>> contributing :) !).
>>>> 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
>>>>
>>>>
>>>>
>>>>
>>>> On Thu, Oct 6, 2022 at 3:44 PM Martynas Jusevičius <
>>>> martynas@atomgraph.com> wrote:
>>>>
>>>>> 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.
>>>>>
>>>>>
>>>> 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.
>>>>
>>>>
>> 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.
>>
>>

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