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

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/

Received on Thursday, 29 September 2022 20:26:59 UTC