Shouldn't gist use a PURL for its namespace IRI?

[pmcb55]

Currently the namespace IRI for gist Core is: https://ontologies.semanticarts.com/gist/, but this IRI is problematic for two big reasons:

• It tightly couples the ontology to the commercial company Semantic Arts, which might make non-USA governments, or non-USA-based corporations, wary of reusing it.
• If Semantic Arts goes away (e.g., is bought out by another company, or it goes bust), then the domain name https://semanticarts.com may no longer exist or be resolvable, thereby preventing lookups. This could make any organization, USA-based or not, wary of having their data contain IRIs that may become unresolvable in future.

Instead it would be advisable (as is very common practice for ontologies generally) to define the namespace IRI using a PURL service, such as https://w3id.org. (Other PURL services could be considered perhaps (but the only other 'major' PURL services that I'm aware of at the moment are European ones like the new https://purl.eu, or https://data.europa.eu/)).

If https://w3id.org were chosen, this would just require the registration of 'gist' and a simple .htaccess file to redirect from a new gist namespace IRI (e.g., something like https://w3id.org/gist/core/) to the current location of the gist ontology, i.e., https://ontologies.semanticarts.com/o/gistCore.

[uscholdm]

This is a good idea. However, we are not exactly sure how this will work. Say we adopt this approach. We create a redirect rule so that when someone types the W3ID URI, it goes to Semantic Arts servers, where we control what is returned. Say Semantic Arts goes bust, so the redirect rule points to a non-functioning domain. How does using permanent URIs help? Who/what will serve up anything useful? How is it any different than what we do now, if we go bust, the domain stops working in both cases.

[rjyounes]

@pmcb55 A couple of additional comments/questions:

• We would like the w3id namespace to include Semantic Arts to identify us as the ontology authors and maintainers, even if the company were to cease to exist. So we would propose https://w3id.org/semanticarts/gist.
• Unlike common practice, we use two different IRIs for the namespace and the ontology IRI. The former is https://ontologies.semanticarts.com/gist/, while the latter is https://ontologies.semanticarts.com/o/gistCore. How will that square with the use of the w3id IRI?
• At the current time, our ontology terms do not resolve over HTTP; I.e., https://ontologies.semanticarts.com/gist/Person returns a 404. The ontology IRI, however, does return RDF. This is something we plan to fix, but until we do, the redirect will not be helpful (though no worse than what's currently (not) in place).

[rivettp]

@uscholdm it would help since someone with "authority" could make a PR with an updated .htaccess file to change the redirect to a functioning server. "authority" could be the original submitter or someone who could make the case/point to evidence that they are a legitimate successor. I subscribe to the w3id GitHub repo and glance at the PR discussions (which are open for anyone to view) https://github.com/perma-id/w3id.org/pulls?q=is%3Apr+is%3Aclosed - the maintainers seem to do a diligent job.

@rjyounes it's up to you whether to keep the separate URIs for w3id.org. In either case the .htaccess file could do what you like with rules for /o/gistcore.
Likewise the rules could redirect https://w3id.org/semanticarts/gist/Person to return the whole ontology as a short term fix to avoid the 404, and later map to something like a DESCRIBE query if you have a SPARQL endpoint.

There's really a lot you can do in .htaccess file - there's a lot of documentation out there or you could look at some of the existing files in the w3id.org repo.

Finally, in case of confusion from the name, this capability is not affiliated with or endorsed by the W3C - it has its own management consortium. Scroll to the bottom of this long page https://github.com/perma-id/w3id.org for who does run and fund it.

[uscholdm]

@rivettp Excellent, very helpful response. So the punch line is the difference is that you can transfer authority. If no one does that, then the benefit disappears - the links will just be broken.

Thanks

[rjyounes]

Our conclusion is:

• We first need to make our IRIs resolve. I'm assigning the issue to Jamie for this step. Dave suggests:

  • First priority is to make sure someone can download the whole file (as is current, that shouldn’t be too hard is it?)
  • Then how about we have an end point with DESCRIBE $URI

• Then change the IRIs and submit the w3id PR with a redirect from https://w3id.org/semanticarts/gist. The issue can be re-assigned to an ontologist to handle this.

[rjyounes]

@uscholdm @Jamie-SA @mkumba Do we want to get the namespace change into v12? @uscholdm has suggested that the release not include an update of this level of impact along with all our other major changes, making migration more difficult. However, it could easily be included in the migration scripts.

I've provisionally put it into the 12.0.0 release for tracking purposes. It can be moved to the next release if that's the consensus.

[Jamie-SA]

I had started to work on this after we discussed it at the fall summit but remember that we had not known the full extent of the changes required when it was discussed. I need to go look at it again...

[Jamie-SA]

It looks like we are going to go ahead with this, but I have a couple of comments I've been thinking about since it was originally requested so I'm going to throw them out here.

One of the original reasons given was:

• It tightly couples the ontology to the commercial company Semantic Arts, which might make non-USA governments, or non-USA-based corporations, wary of reusing it.

Does this really go away if semanticarts is still in the URL such as: https://w3id.org/semanticarts/gist?

Also, I think that argument doesn't acknowledge the benefits of having a known company actively developing it and using gist in many large enterprise projects and the 20 years of learning embodied in the work. When choosing open source technologies to build on, I find it reassuring to have a large corporation backing and contributing to it.

[rjyounes]

I proposed adding /semanticarts/ into the namespace, but not the domain, because I think it addresses both the original concern and the one you raise. We eliminate the technical coupling to the Semantic Arts domain and servers, as requested by Pat, but we retain an association between Semantic Arts and gist. This namespace can be retained even if the ontology maintenance is transferred to another organization or persons. From: Jamie-SA ***@***.***> Date: Tuesday, May 9, 2023 at 5:01 AM To: semanticarts/gist ***@***.***> Cc: Rebecca Younes ***@***.***>, Mention ***@***.***> Subject: Re: [semanticarts/gist] Shouldn't gist use a PURL for it's namespace IRI? (Issue #683) It looks like we are going to go ahead with this, but I have a couple of comments I've been thinking about since it was originally requested so I'm going to throw them out here. One of the original reasons given was: * It tightly couples the ontology to the commercial company Semantic Arts, which might make non-USA governments, or non-USA-based corporations, wary of reusing it. Does this really go away if semanticarts is still in the URL such as: https://w3id.org/semanticarts/gist? Also, I think that argument doesn't acknowledge the benefits of having a known company actively developing it and using gist in many large enterprise projects and the 20 years of learning embodied in the work. When choosing open source technologies to build on, I find it reassuring to have a large corporation backing and contributing to it. — Reply to this email directly, view it on GitHub<#683 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAM5PZB5JU5F6KD5VIVO7H3XFIBWXANCNFSM5YLFQVPQ>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[rjyounes]

DECISION:

• gist namespace change to w3id.org domain
• Ontology IRI returns the entire ontology, as currently
• What does the namespace IRI return?
  • Text explaining why ontology IRIs and namespaces are not the same.
  • If you want the ontology: Link to the ontology
  • If you want to know more about gist: Link to the gist page on SA website
  • Link to gist documentation

Tasks:

• Submit PR to w3id with update to .htaccess file for redirect to SA server - Jamie
• Replace namespaces in all files in gist repo - Colton; see issue Replace namespaces in all files in gist repo #853.
• Replace ontology IRIs, version IRIs, and gist import IRIs in all files in repo - Colton. See issue Update ontology IRIs, version IRIs, and import IRIs in all gist ontologies #859.
• Create web page to display for namespace IRI - Dave; see PR Add docs/Namespace.md (from Dave) #852.
• Maybe documentation changes in repo docs - Rebecca. No changes required.

Future follow up Tasks:

• IRIs of individual ontology terms should return HTML. - Jamie
  Later step would be to use content negotiation to return either RDF or HTML. See issue IRIs of individual terms should be dereferenceable over HTTP #130. -
• Update website links - Jamie Update website links per #816 (Follow-on to 12.0 release) #870
• Peter's eBook - Peter Peter's eBook (follow-on to 12.0 release) #869

Submit one PR for each item above.

• Namespace: https://w3id.org/semanticarts/gist/
• Ontology IRI: https://w3id.org/semanticarts/gistCore

[pmcb55]

Hi all - firstly, I'm really sorry that I completely missed all the posts on this thread until Dave pinged me a couple of days ago! (Yes, I am 'Watching' this repo, but for some reason I don't get the notifications of changes (probably 'cos I've so overly-restricted my email filters, as I have to try and 'Watch' lots of repos/Confluence instances from customers/Jira repos/GitBucket repos/etc.)).
But secondly, I'm really impressed (again!) with the above discussion, and (again!) I 100% agree with the outcome you folks have arrived at here.
For example:

1. Yep, I totally agree that keeping /semanticarts/ in the Namespace IRI is actually better than what I originally suggested. The only 'important' part of the Namespace IRI is the domain, as that determines 'who' controls the full IRI. By changing that to w3id.org you've introduced the critical layer of indirection in that 'who', and that's all that really counts.
   The fact that you've slotted in /semanticarts/ in there too is actually a wee bit better I think, as, for humans, it provides a nice little bit of (potentially, over time, if/when Semantics Arts is bought out, or disappears - historical) information on where this vocab originated, which I think is really 'nice' (and machines couldn't care less what's in an IRI after the domain part (apart from pesky hashes '#' in there though of course, but that's a whole other topic...!)).
   So yeah, to @Jamie-SA - my concern really does "go away if semanticarts is still in the URL", 'cos it's no longer in the domain.
2. Yep, I also agree with gist's stance on: "Unlike common practice, we use two different IRIs for the namespace and the ontology IRI". I had a big lightbulb go off in my head over dinner with @uscholdm in Fort Collins last year as he explained the rationale for that. So much so in fact that I've now incorporated that into Inrupt's vocab Best Practices, and applied it to all our internal vocabs.
   In other words, I think we should all be encouraging that to become the "common practice" :) !
3. And yep, I totally agree with @rjyounes wish to have the entire vocab resolve as RDF via it's Namespace IRI, and also for individual terms to also resolve as RDF (and in both cases to support content negotiation for providing HTML too). The best example I know of that working well today is QUDT (e.g., https://qudt.org/schema/qudt/CurrencyUnit). But yeah, I also agree that that is kinda a separate topic to the Namespace IRI issue itself (but yeah, the simple .htaccess rewrite rules from w3id.org can certainly be helpful in providing that for you too, if you like. By the way, I really like the idea of a DESCRIBE $IRI endpoint too, although I'd assume that would then involve running a database/triplestore with a SPARQL engine, and then that gets into providing redundancy/failover/availability zones/etc/ for that database server instance(s) - as opposed to simply serving up static files from something like a small cluster of Apache or Nginx webservers. For instance, I like Widoco a lot (for generating static documentation pages from vocabs), but unfortunately it doesn't (yet!) support generating a HTML-page-per-vocab-term: Can Widoco generate a HTML page per term? dgarijo/Widoco#559).