- From: Jo Rabin <jrabin@mtld.mobi>
- Date: Tue, 13 Mar 2007 08:58:58 -0400
- To: <public-ddwg@w3.org>
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 12:59:09 UTC