RE: Naming conventions

Hello everyone,

I note that a number of people have commented on Rotan's suggestion. I'll reply to his mail, but that doesn't mean I'm ignoring Magnus who also replied.

It turns out that there are some guidelines from the sem web community. They tend to be more along the lines of remembering that the names in the ontology represent relationships, hence the use of names such as hasBlah or supportsFoo. Actually, the conversation from last week about instances, defaults and ranges could well affect the names currently in use. So Jo's comment is germane to at least part of this discussion. And I agree that the names and structure of the existing ontology are far from 'correct'.

We do need to have a rationale for naming. Actually, we may need more than one. Something I mentioned in a recent post is that, along with the 'ontology names' for things, each class and property in the ontology can have additional associated names. The idea was that we could provide additional names more appropriate for programming languages (IDL?) and interfaces than ontologies. At the moment I've got the ability to specify camel case (Java style) and hyphenated names (scripts perhaps?) but we can create additional ones very easily.

It seems to me that these alternate names are where Rotan's suggestion of mapping particular types to particular name patterns would fit. For the 'ontology names' (the ones in the Name column of the tables in 
http://lists.w3.org/Archives/Member/member-ddwg/2007Mar/att-0066/DCOntology-20070228-try1.html)
we should probably stick with sem web best practices (if they say something useful). For the alternate names, we can then apply the most appropriate language-style of pattern. So in Rotan's example, the notion of a name like isFoo' being a boolean would fit with most OO languages and might appear as the camel case name for that property and in any others as needed. As I say, we can have as many types of alternate name as we like, subject to the editor's ability to type them all in!

There are only a few entries in the ontology at the moment with alternate names, and most are classes. You can see an example of alternate names for properties in the documentation at 

http://lists.w3.org/Archives/Member/member-ddwg/2007Mar/att-0066/DCOntology-20070228-try1.html#aspect-ratio

Hmm, I've just noticed that that document is not being served with a UTF-8 encoding, so you may need to choose UTF-8 as the character encoding in your browser to avoid the odd characters in the TOC and possibly elsewhere (cardinality values for example).

Best wishes
Rhys
 



-----Original Message-----
From: public-ddwg-request@w3.org [mailto:public-ddwg-request@w3.org] On Behalf Of Rotan Hanrahan
Sent: 13 March 2007 14:20
To: Jo Rabin; public-ddwg@w3.org
Subject: RE: Naming conventions


I am not saying anything with respect to the discussions of last week or the week before. This is only about choosing names for instances. I have nothing to say about ScreenOrientation. I am concerned only with naming patterns. In the example ontology presented by Rhys there is a pattern appearing in the names. Some names appear to have a prefix. The prefix has no actual bearing on the ontology. The actual names have no bearing on the ontology. We could just as easily call our instance names A, B, C, etc and the ontology would still be valid. But we choose not to do that. Instead we choose to use names that have some meaning to English speaking people. Hence things like ScreenOrientation. But when the names appear to have a pattern, like "hasABC", then it is natural for a human to attribute some meaning to this pattern.

I am suggesting that this natural tendency of humans to see patterns in names could be used to the benefit of those who will use the results of this group. Therefore, a naming convention is something that would be useful. We could, for example, indicate that names beginning with "has", "is", "can" in situations where Boolean is a type that can be used, then Boolean will in fact be the type used. As another example, the prefix "numberOf" could be used to signal non-negative integer types.

These are merely conventions. They have no technical bearing on the actual ontology.

And there is no requirement to decorate names. The convention can simply indicate that only certain reserved prefixes have suggestive meaning, whereas all other names can only be typed by inspection of the vocabulary.

This would only work if the naming convention was enforced.

If, however, we do not adopt a naming convention, we could run into the trap of having many names that have the pattern "hasABC" and are Booleans, and thus giving the software developer the incorrect idea that all entities so named are Booleans. Then the day comes when a non-Boolean "hasXYZ" entity appears, and the developers are confused by this apparent break in an unwritten convention. Given human nature, I would rather we have a clear convention from the outset. It can be very simple, and should cover many common cases. And it should be easy to see when a name is not following a convention.

Ranges, enumerations, sets etc are things I expect would probably not fit a naming convention. But the common data types (Boolean, Integer, Float) should be decorated. I am a bit unsure about whether String should be decorated, as in many cases it is merely a representation of an underlying type.

To reiterate... I don't want to revisit the previous discussions on the ontology. This, I believe is orthogonal.

---Rotan.

Received on Tuesday, 13 March 2007 18:30:04 UTC