W3C home > Mailing lists > Public > public-ddwg@w3.org > March 2007

RE: Naming conventions

From: Jo Rabin <jrabin@mtld.mobi>
Date: Wed, 14 Mar 2007 12:32:56 -0400
Message-ID: <815E07C915F39742A29E5587B3A7FA192A17B729@lk0-cs0.int.link2exchange.com>
To: <public-ddwg@w3.org>

A couple of rejoinders on the names:

a) To elaborate on what Rhys says below, if we were to name the
attributes after the relationship then we would have different
attributes for canHaveNumberOfAerials, hasByDefaultNumberOfAerials and

A developer accessing this information would probably want to know all
three of these by the same name: NumberOfAerials. The developer would
distinguish between the different aspects or manifestations by something
in the API, I would think.

b) I imagine that it will be common for the different aspects or
manifestations to have different data types. E.g. NumberOfAerials
(canHave) might well be a set of integers, whereas NumberOfAerials (has
by default) is an integer. 

The consequence, to my mind, is that putting the data type in the name
is could be fraught with difficulties.

c) The converse, though, as Rotan points out is also dangerous - i.e. if
the name accidentally contains something that might make Jo Developer
assume a datatype - that should be avoided too. Does this mean that we
should ban the use of has... and supports... as prefixes?

d) If we do decide to decorate the names, I am concerned doing this too
early in the process. The data type might well change in the course of
development. Our early assumptions about data types may well constrain
our thinking and we might get locked into false assumptions. E.g. when
we say Boolean, do we actually mean True, False and Don't Know?


> -----Original Message-----
> From: Rhys Lewis [mailto:Rhys.Lewis@volantis.com]
> Sent: 13 March 2007 18:29
> To: Rotan Hanrahan; Jo Rabin; public-ddwg@w3.org
> Subject: RE: Naming conventions
> Hello everyone,
> I note that a number of people have commented on Rotan's suggestion.
> 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
> They tend to be more along the lines of remembering that the names in
> ontology represent relationships, hence the use of names such as
> or supportsFoo. Actually, the conversation from last week about
> defaults and ranges could well affect the names currently in use. So
> comment is germane to at least part of this discussion. And I agree
> the names and structure of the existing ontology are far from
> We do need to have a rationale for naming. Actually, we may need more
> one. Something I mentioned in a recent post is that, along with the
> 'ontology names' for things, each class and property in the ontology
> 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
> camel case (Java style) and hyphenated names (scripts perhaps?) but we
> create additional ones very easily.
> It seems to me that these alternate names are where Rotan's suggestion
> mapping particular types to particular name patterns would fit. For
> '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
> of a name like isFoo' being a boolean would fit with most OO languages
> 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
> subject to the editor's ability to type them all in!
> There are only a few entries in the ontology at the moment with
> names, and most are classes. You can see an example of alternate names
> 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
> 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
> (cardinality values for example).
> Best wishes
> Rhys
> -----Original Message-----
> From: public-ddwg-request@w3.org [mailto:public-ddwg-request@w3.org]
> 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
> the week before. This is only about choosing names for instances. I
> nothing to say about ScreenOrientation. I am concerned only with
> 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
> no actual bearing on the ontology. The actual names have no bearing on
> ontology. We could just as easily call our instance names A, B, C, etc
> the ontology would still be valid. But we choose not to do that.
> we choose to use names that have some meaning to English speaking
> Hence things like ScreenOrientation. But when the names appear to have
> pattern, like "hasABC", then it is natural for a human to attribute
> meaning to this pattern.
> I am suggesting that this natural tendency of humans to see patterns
> names could be used to the benefit of those who will use the results
> this group. Therefore, a naming convention is something that would be
> useful. We could, for example, indicate that names beginning with
> "is", "can" in situations where Boolean is a type that can be used,
> 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
> ontology.
> And there is no requirement to decorate names. The convention can
> indicate that only certain reserved prefixes have suggestive meaning,
> whereas all other names can only be typed by inspection of the
> This would only work if the naming convention was enforced.
> If, however, we do not adopt a naming convention, we could run into
> trap of having many names that have the pattern "hasABC" and are
> 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
> break in an unwritten convention. Given human nature, I would rather
> have a clear convention from the outset. It can be very simple, and
> cover many common cases. And it should be easy to see when a name is
> following a convention.
> Ranges, enumerations, sets etc are things I expect would probably not
> a naming convention. But the common data types (Boolean, Integer,
> 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
> type.
> To reiterate... I don't want to revisit the previous discussions on
> ontology. This, I believe is orthogonal.
> ---Rotan.
Received on Wednesday, 14 March 2007 16:33:10 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:00:13 UTC