[sc34wg3] Unique names in Draft Reference Model

[Steven R. Newcomb]

"Anthony B. Coates" <abcoates@TheOffice.net> writes:

> ** Reply to message from "Steven R. Newcomb" <srn@coolheads.com> on 30 Dec 2002
> 21:04:12 -0600
> 
> > Here's an equally good question: Why shouldn't they
> > share the same namespace?  What's the advantage of
> > having separate namespaces for these things?  Would the
> > advantage of making separate namespaces outweigh the
> > disadvantage of having to invoke the right one them
> > whenever referring to a property, or an assertion type,
> > or a role type?  I think that having separate
> > namespaces would require all of these identifiers to
> > have three fields.  Isn't a TM Application likely to be
> > more robust, and less prone to errors and
> > misunderstandings, if everything is required to have a
> > unique name?
> 
> No, I don't think so.  Over the holiday period, I've
> been analysing the RM to produce a UML model, and a
> logical (relational) database model.  Not quite
> finished yet, but based on this analysis, I cannot
> see a situation where it would be a problem to allow
> a property to have the same name as an assertion/role
> type.  I'm less sure about whether assertion/role
> types might be subject to confusion.

> From the point of view of writing an application,
> every field in every class effectively defines a
> separate namespace for values, so separating
> namespaces is not an issue, it is just normal
> practice.  However, if property names have to be
> distinct from assertion/role type names, that adds a
> layer of cross-checking which is a burden on the
> application.  My point is that I don't see any gain
> as a result of that burden, which makes me think it
> is unnecessary.  I would suggest that properties,
> assertion type names, and role type names should have
> separate namespaces until such time as someone can
> identify a situation where having the same name leads
> to an unresolvable ambiguity.

I think your points are valid, but there's more to the
story.

* I suspect you're right when you say that, in
  relational and/or UML terms, it's not a problem for a
  property to have the same name as an assertion type.

* You are also right when you say that it's a burden
  for applications to check whether there are
  homonymous properties and assertion types.  However,
  it's not clear that checking within one of two or
  three namespaces is significantly less burdensome
  than checking within a single, somewhat larger
  namespace.  The burden looks even smaller when we see
  that the need to "cross-check", as you put it, only
  appears in applications that assist people in
  designing TM Models.  As you and I both suspect, it
  doesn't come up at all when people are creating or
  using topic maps.  Once the names used to identify
  the components of a TM Model have been validated for
  uniqueness, they remain so.

* For me, the primary reason for having a single
  namespace is not technical; it's human.  Having a
  single namespace is a significant advantage for human
  beings who are trying to talk with each other about
  TM Models.  With a single namespace within which
  every aspect of a given TM Model has a unique name,
  we can speak to each other unambiguously, without
  having to be painfully precise every time we open our
  mouths.  We can say only "zorp", instead of having to
  say "the zorp assertion type", or "the zorp role
  type", or "the zorp SIDP", since "zorp" can mean only
  one thing (whichever it is).  (As a standards
  developer yourself, you know how hard it is to
  establish an unambiguous universe of discourse.
  Considering the vanishingly small price of this
  "single namespace" idea, and the potentially enormous
  cost of misunderstandings regarding TMs and what they
  mean, doesn't the single namespace idea make sense to
  you, too?)

-- Steve

Steven R. Newcomb, Consultant
srn@coolheads.com

Coolheads Consulting
http://www.coolheads.com

voice: +1 972 359 8160
fax:   +1 972 359 0270

1527 Northaven Drive
Allen, Texas 75002-1648 USA