Re: Switch DPV namespace IRI to use slash instead of hash?

Hi Harsh,

Thanks for feedback - yeah, I'll create an issue in the GitHub repo so...

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, Sep 29, 2022 at 9:26 PM Harshvardhan J. Pandit <me@harshp.com>
wrote:

> Hi Pat.
>
> tldr;
> Personally, I have no specific opposition to adoption of slash as a
> differentiator in the IRI. And the argument you have stated makes sense
> to me. However, I do not support this change because: a) it would
> completely break the existing IRIs and anything that uses them; b) there
> are not enough benefits to offset breaking things; c) this will delay
> our v1 release schedule well into 2023 - which I would prefer not to
> happen.
>
> Others are welcome to express their opinions.
>
> There's a term for earlier decisions making changes harder:
> https://en.wikipedia.org/wiki/Technical_debt
>
> ---
>
> If you can point to an authoritative or community (re)source that says
> slashes are the recommended way to build IRIs - we have a justification
> for why we are discussing such a major change. Otherwise there are
> existing counters where major vocabularies also use hash in their IRIs -
> DCAT, EU (and aligned e.g. SEMIC) vocabularies, PROV, Time, SHACL, etc.
> - which give inertia to continue with what we have.
>
> At this stage in the development of DPV, which is ~5 years after its
> development - I'm wary such a change would mean existing IRIs breakdown
> completely - which is not only a major change that affects existing
> users, but it also disrupts existing uses of DPV and workflows built
> using it. So I question whether there are sufficient gains to counteract
> the drawbacks.
>
> I'm open to be convinced otherwise to move our IRIs to use slashes -
> primarily if there enough members who support this notion and they have
> addressed (if any) objections. Until then, I would not support this
> since IMHO it doesn't provide enough tangential benefits to offset the
> cost of change - which is quite high.
>
> ---
>
> You are welcome to keep the discussion going. My suggestion is that you
> should open a GitHub issue so we can easily see the discussion in one
> place, and people have an easy mechanism to support/object (e.g. thumbs
> up / down).
>
> Though do note that DPV is intended to be released as v1 soon, with
> OCT-15 set as the date for feedback, and NOV for the release. There
> isn't sufficient time to notify existing adopters nor seek their
> feedback. So pragmatically, we probably will have to continue with what
> we have. Delaying this is also not a good alternative since we have no
> knowledge of how much time this would take, and also because we have
> been discussing v1 for close to a year now.
>
> --
>
> In saying all this, I also want to emphasise that DPVCG is not a
> semantic-web focused group in the conventional sense, and nor am I an
> expert in semantic web. Therefore, the semantic web mailing list might
> be a better forum to discuss and seek consensus given the amount of
> people involved as well as their collective expertise and experience. We
> can then discuss how to implement the identified best practices from there.
>
> Regards,
> Harsh
>
>
> On 29/09/2022 20:30, Pat McBennett wrote:
> > Hi,
> >
> > I'd like to propose that the DPV group consider switching the DPV
> > namespace IRI to use a trailing slash instead of a hash, i.e., using
> > https://w3id.org/dpv/ <https://w3id.org/dpv/> instead of the current
> > ttps://w3id.org/dpv# <http://w3id.org/dpv#>
> >
> > I'm guessing that DPV probably just chose to use a hash because it tends
> > to be more common (and has been typical for W3C vocabs), but there are
> > pro's and con's to either choice (as explained briefly in "2.2 Hash
> > versus slash URIs" of this paper <https://arxiv.org/pdf/2003.13084.pdf>,
>
> > but the paper doesn't recommend one over the other).
> >
> > Personally I consider that using slashes is 'more correct', since it's
> > the only option that allows both 'getting all vocab metadata in a single
> > request' (i.e., just dereference the namespace IRI itself), and 'getting
> > just the metadata for an individual vocab term'.
> >
> > It certainly seems much more correct to me that clicking on
> > https://qudt.org/schema/qudt/CurrencyUnit
> > <https://qudt.org/schema/qudt/CurrencyUnit> in my browser returns only
> > information on QUDT's definition of a 'CurrentUnit' (try it yourself!),
> > or simply executing "curl https://qudt.org/schema/qudt/CurrencyUnit
> > <https://qudt.org/schema/qudt/CurrencyUnit> -H "Accept: text/turtle""
> > gives me back */only/* the relevant triples in Turtle (Turtle is
> > actually the default, so the `Accept:` header isn't even necessary).
> >
> > The same is demonstrated nicely with any term from Schema.org. If they'd
> > made the mistake of using hashes, then simply looking up what a
> > 'https://schema.org#Person <https://schema.org#Person>' was would
> return
> > information for all 2,300+ terms in Schema.org, which is simply not what
> > was requested or intended at all.
> >
> > Yes, it can be a bit more work for the server hosting vocabs to support
> > both options, but adopting slashes now at least makes providing that
> > flexibility possible later, whereas continuing to use a hash makes it
> > impossible forever!
> >
> > Major vocabs like Schema.org, Gist, QUDT, FOAF, BIBO, ODRL, SAREF, SOSA,
> > SSN, etc. all use slashes, so it's certainly not uncommon, and in fact I
> > understand that the Gist community
> > <https://www.semanticarts.com/gist/> (recommended by Oracle
> > <
> https://www.ateam-oracle.com/post/knowledge-graph-modeling-governance-project-scope>)
> discussed this very question back in 2019, and after careful consideration
> and discussion, it was decided to flip from using hash to use slash
> instead. (*_Note_*: I did reach out to the gist community to ask if they
> have a public record of the discussions they had that led to them switching
> from hash to slash (see here <
> https://github.com/semanticarts/gist/issues/725>), but unfortunately they
> don't seem to have a record at all!).
> >
> > So I think DPV should very seriously consider adopting the slash instead
> > of hash too.
> >
> > 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.
>
> --
> ---
> Harshvardhan J. Pandit, Ph.D
> Research Fellow
> ADAPT Centre, Trinity College Dublin
> https://harshp.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.