RE: Naming conventions

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
hasInstalledNumberOfAerials.

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?

Jo

> -----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.
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 16:33:10 UTC