Define and implement conventions for local names

[rjyounes]

This is a spin-off of #20, which we decided to limit to labels. Conventions articulated there for composing local names are repeated below. The gist Style Guide (forthcoming) also records these conventions, but only as proposals since there remains significant controversy.

Classes: camelcase, initial uppercase. Acronyms also camel-cased so that word boundaries are unambiguous - e.g., AmaGuideline not AMAGuideline, UriScheme not URIScheme. Alphanumeric characters only - e.g., Isbn10, not Isbn-10 or ISBN-10. ID is an exception: Merriam-Webster accepts this as a word in all-caps.

Properties: camelcase, initial lowercase, acronyms as above.

Both: non-standard abbreviations should not be used: e.g., hasUoM should be hasUnitOfMeaure.

[rjyounes]

This is a minor change based on semver criteria.

[rjyounes]

The issue will be raised at the gist council meeting on March 5 to canvas user reactions to the proposed URI changes (or indeed any URI changes).

For SA ontologists, Dan's proposed changes are now on the Semantic Arts One Drive for commenting. A link will be sent in an email.

[rjyounes]

Comments from SA ontologists:

Dave McComb, March 1:
Does this automatically save? Can others see my comments?

My general thoughts are two fold:
Are these suggestions an improvement?
Are they worth the hassle of migration

Obviously we have to answer them in that order. It is possible they are an improvement but not worth the trouble. However if they are not an improvement, then we don’t need to worry about the migration.

To me, most of them are not an improvement, and many are a deprovment (if that is a word, which apparently my spell check doesn’t think so). But that’s just one ontologists opinion.

Michael Uschold, March 2:
Things evolved organically over many years, and now several different conventions are used. Most individual changes are not improvements. The main idea was a collective improvement: to have consistent predictable naming conventions across the board. One view shared by several of us is that this kind of consistency gives gist a cleaner and more professional look.

Dave McComb, March 2:
Some of this, like the desire to have verbs in the names, stems from a valid desire to telegraph the directionality of the predicate. The skos:broader failed that, as half the population thinks it is pointing at the boarder term and half seem to think it means broaderThan. So we definitely want to stomp out ambiguity (and we had a couple like that in gist, not sure if I recall any now)

But reflexively adding “is” and “has” on the front of property names not only doesn’t assure this goal is achieved, it makes the names longer and more unwieldy without much benefit. For instance if we were skos, just adding an “is” doesn’t really solve the problem “isBroader” is still ambiguous. It’s the “than” which breaks the ambiguity. (although that is if you wish to point from the broader to the narrower, pointing the other way is still problematic, you almost have to say hasBroaderTerm or something, although I don’t like putting the range in the predicate name, unless really have to. )

Seems to me a lot of these add nothing, and make it more clumsy in the bargain. Is “hasActualTimeInstant” really better than “actual” Is “isCategorizedBy” better than “categorizedBy?”

Dan Carey, March 2:
Part of the rationale for the changes is to provide clarity.

In the absence of the TBox schema, if a triple says ":_x :actual :_y", a human has no idea what :actual means. And in the absence of the sort of IRI naming scheme we promote, a human wouldn't know what :_y is. Since we do have a range specified for :actual, it makes sense IMO to append an indicator of the range to prevent its misuse. Hence :hasActualTimeInstant.

Leaving off the "has" makes the property name a noun instead of a verb. The consensus, as I understand it, has been that we should use verbs for object properties, nouns for data properties. Granted, the "is" and "has" prefix gets repetitive when looked at. But I think the enhanced semantics make it worth the cost.

Michael Uschold, March 2:
All of Dave’s comments here address what particular conventions to use – and are up for discussion. There are no right answers . For example, I also am not a great fan of adding izzes all over the place. But that is just one of a number of decision points about what our conventions should be. It is separate from deciding that we will have a single set of conventions and consistently use them everywhere.

[rjyounes]

I do not have a hard-and-fast opinion, but there are a couple of reasons for consistently using verbs for object properties - which sometimes results in "is" or "has" when no other verb is available or idiomatic:

1. Explicitly distinguish them from datatype properties
2. Assuming we adopt the verb-first convention, my rationale for adding "is" to "ed" forms (categorized, connected, etc.) is:
   a. In English these forms are sometimes passive participles (verbs) and sometimes adjectives. I proposed the "is" form to relieve the ambiguity. E.g., "connected" is an adjective since we do not care about the act of connecting but the state of being connected. "preceded" is a passive participle. Rather than a complex rule about adjectives vs passive participles, I've proposed always using "is."
3. "is" reads better: X isConnectedTo Y rather than X connectedTo Y.

So I'm agreeing with Dan's comment above.

Dave is correct that "isBroader" and "isNarrower" still require "Than." But "hasBroader" and "hasNarrower" are unambiguous. Choosing the right verb is necessary to unambiguously indicate directionality.

Regarding Dan's hasActualTimeInstant, I'm generally not in favor of appending the object type to the predicate and prefer to make the names semantic rather than structural. Maybe "hasActualDatetime"? There may be better options, but I again agree with Dan that "hasActual" doesn't indicate meaning.

[rjyounes]

Regarding Michael's point, there are indeed a couple of distinct issues:

• Should we establish conventions? I'm hoping we all answer yes to this one.
• If yes, what should the conventions be? (this is going to be hard to reach consensus on)
• Again if yes, should they be applied to existing terms - I.e., change existing URIs - or only apply moving forward? Those who, like Dave, are not in favor of disrupting the URIS may nevertheless agree that, whatever the defined conventions are, they should be applied in future.

[rjyounes]

Feedback from gist Council participants March 5: everyone generally in favor, no one raised serious migration concerns. Deprecation rather than removal of original terms is key.

[rjyounes]

Defer till next major release.

[rjyounes]

Raise at an internal meeting. Assigning to myself to get on the agenda.