I think naming things like projects and repositories and folders can be tricky. I don't think naming schema fields should be very tricky. Problems with names in schemas usually reflect limitations of the technologies involved. From your example:
database has page.page_namespace. This is mostly for clarity in SQL statements. The name of the table is duplicated in the name of the field so you can make sense of fields across joins and complicated subqueries.
javascript has wgNamespaceNumber. Looks like a convention dictated this, but luckily it's fairly isolated from research work so we can ignore such things.
XML has <page><ns>. This is the closest to free of idiosyncrasy, but ns should be namespace and it probably isn't to conserve space in dumps (which can get large)
Finally we're considering page_namespace_id. I disagree and I can make an objective argument. We're going to use a json object to represent this data. It should therefore be:
{ page: { namespace: 0 } }
There is no namespace table, and so the namespace is not an id. It's a number that means different things based on configuration in different wikis. If we decide to make a namespace entity with (wiki, number, description) properties, then it would be ok to have:
{ page: { namespace_id: 0 } }
As a side note, naming matters for our data warehouse as well. I say we don't limit ourselves with tool idiosyncrasies. Instead, let's come up with names that make sense. Veteran researchers can rid themselves of the pain of old names, but new researchers shouldn't have to deal with legacy naming. And hopefully for the veterans out there, the structure of the json document is enough to make up for the new approach.