- From: Rotan Hanrahan <rotan.hanrahan@mobileaware.com>
- Date: Tue, 13 Mar 2007 14:19:45 -0000
- To: "Jo Rabin" <jrabin@mtld.mobi>, <public-ddwg@w3.org>
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. -----Original Message----- From: public-ddwg-request@w3.org [mailto:public-ddwg-request@w3.org] On Behalf Of Jo Rabin Sent: 13 March 2007 12:59 To: public-ddwg@w3.org Subject: RE: Naming conventions I'm not completely clear what your proposal is ... to revisit momentarily the discussion of last week and the week before ... In the general case the device repository will contain an enumeration (range or whatever) of possible values, whereas the value for that attribute for an instance of a device will often be a single value. So, if the repository says that ScreenOrientation can be either landscape or portrait how would you want to decorate that name? Thanks Jo [1] I think that Rhys told us that is what they are called in respect of the delivery context, so if I am right, let's stick with that. ________________________________________ From: public-ddwg-request@w3.org [mailto:public-ddwg-request@w3.org] On Behalf Of José Manuel Cantera Fonseca Sent: 13 March 2007 12:08 To: Rotan Hanrahan Cc: public-ddwg@w3.org Subject: Re: Naming conventions +1 for the naming conventions, perhaps we could get advice from the "Semantic-Web Best Practices and deployment working group" for guidelines on naming conventions What do you think? Best Wishes Rotan Hanrahan escribió: As we move closer to figuring out how to use Protégé to create our ontology for the Core Vocabulary, I would like to ask if we should adopt a naming convention for properties/attributes/classes/whatever? Strictly speaking, the names should be irrelevant because this data is processed by a machine and machines don't speak natural languages. But I also have a concern for the ordinary software developers, who like a bit of "self documentation" in method names, variable names etc. For this reason, it would be good if we had a few simple rules to make the ontology (and subsequent vocabulary) self-documenting from a human point of view. For example, it would be good if the name of a property suggested a type, such as "hasABC" would always imply a Boolean type. (I come from a formal background, so I know of the dangers of implied typing (e.g. Hungarian Notation) but we should be able to enforce the relationship if we control the ontology properly.) Take the samples that we have been using internally as we learn how to use Protégé. We have cases of hasABC and supportsABC (both Booleans) and we have cases of hasABC and supportsABC being non-Boolean. While this is valid from a formal perspective, a typical developer using these names might express some doubt as to whether compatible types were being used. What do others think? ---Rotan Sample from our ongoing experiments with Protégé: hasPointingResolution PointingResolution Pixel supportsBluetoothProfiles BluetoothProfile Dialup Networking supportsInputCharacterSets CharacterSet WINDOWS-1252 supportsVoiceRecognition Boolean true hasNumberOfSoftKeys int 0 hasTextInputType TextInputType Alphanumeric hasPrimaryCPU CPU ARM9 hasDeviceName string Sony Ericsson P910i hasProportionalDefaultFont Boolean true supportsAudioOutput Boolean true hasDisplay Display Display_SonyEricsson_P910 supportsOutputCharacterSets CharacterSet WINDOWS-1252 hasTactileInputType TactileInputType Full Keyboard
Received on Tuesday, 13 March 2007 14:20:35 UTC