Re: Naming conventions

Hello all,
	coming a little late, and using Rhys' e-mail to catch up with all  
the previous.

I support the idea of a naming convention.

I'm also glad Rhys mentioned that some people might be comfortable  
with camelcase and some others might not. I don't have a problem with  
it, but I like better the old style has_second_screen rather than  
hasSecondScreen. In my experience it's easier and avoids errors of  
capital or non-capital letters. I guess who has been using this for  
10 years never has an issue today, of course, but if you frequently  
move from Java to PHP to python you might have a problem.

Alternate names might sound like a solution, anyway I'd like this  
group to stick to a single name for each entry that we'll have. A  
real world example are J2ME JSR's, each has a number and a name and I  
can tell you most people knows all the numbers OR all the names, but  
not both and when two people with two different backgrounds meet and  
talk, they basically can't communicate. I would like to avoid this.

I don't think there is a single naming standard that will be better  
than any other all the time, each has some advantages and all really  
depend on how frequently you use them and how much you're used to it.  
We could have a poll about this, for example.

What I think is important is that we agree on having a convention.

- Andrea

Il giorno 13/mar/07, alle ore 19:28, Rhys Lewis ha scritto:

>
> 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 Wednesday, 14 March 2007 08:48:25 UTC