GeoNames Forum

The RDF dump has been updated to use https: URLs instead of HTTP URLs. Ok agreed, even though this is a breaking change for anyone who uses Geonames URLs in their own RDF data.

gn:featureCode, gn:featureClass also use https URLs, eg <https://www.geonames.org/ontology#P.PPL>.
However, their definitions in geonames-ontology_v3.1.ttl still use http URLs, which means that these https nodes are left without undefined (no type, skos:prefLabel, etc)

"Upgrading" the ontology to use https would be a big burden because then EVERY SPARQL query in the world that uses Geonames data would need to be upgraded. It's also pointless, because the ontology (including feature codes) is not served online.

So the best option is to change back gn:featureCode, gn:featureClass to use http and not https values.

I'm posting this as STICKY because it's a breaking bug in the RDF representation. Thanks!

Thank you for raising this important issue! The transition to HTTPS for Geonames URLs in the RDF dump is certainly a significant step forward in terms of security and modern web standards, but I understand the concerns about its implications for existing systems and SPARQL queries.

Your suggestion to revert gn:featureCode and gn:featureClass to HTTP URLs seems reasonable, especially given the potential disruptions and lack of direct benefits from upgrading the ontology to HTTPS. Ensuring consistency between the RDF data and the ontology definitions is crucial for maintaining usability and avoiding undefined nodes, as you’ve pointed out.

That said, I wonder if there might be a middle ground. Could we:

Introduce a temporary mapping or redirect mechanism for users to resolve both HTTP and HTTPS URLs without breaking their existing queries?
Publish a clear migration guide for developers, outlining steps for transitioning their SPARQL queries to align with HTTPS URLs while minimizing disruptions?
Consider an updated ontology release (v3.2?) with HTTPS URLs, but maintain the older version (v3.1) with HTTP URLs for backward compatibility. This way, developers can adopt the new standard at their own pace.
Making the change back to HTTP is indeed the quickest fix, but planning for a gradual transition to HTTPS in the long term could future-proof the ontology while minimizing the immediate impact. Happy to hear other perspectives on this!

Making the change back to HTTP is indeed the quickest fix

My suggestion pertains to ontology terms and featureCodes/Classes. Not to place URLs.

Consider an updated ontology release (v3.2?) with HTTPS URLs, but maintain the older version (v3.1)

That will work well: people can load the ontology of their choice.
However, the Geonames dump should also have 2 versions. Both using the same https URLs for places, but the two differing as to which version of ontology terms they use.

Redirects are useful to ensure that Geonames entity RDF are accessible either way.
But SPARQL queries don't care about redirects: they query precisely for the ontological terms that are loaded in a particular repository. So if you want to preserve existing queries, you need to offer 2 versions of the dump.

Hi

Sure we can go back to http.
Any objections?

Best Regards

Marc