Re: [namespaceDocument-8] 14 Theses

[Patrick Stickler <patrick.stickler@nokia.com>]

On 2002-02-18 8:00, "ext Tim Bray" <tbray@textuality.com> wrote:

> We have general agreement that the issue of "namespace
> documents" is one that deserves further study.  I spent
> some time over the weekend trying to get my thoughts and
> arguments in order and have published them at
> 
> http://www.textuality.com/tag/Issue8.html
> 
> Note that this also takes care of my action item to say
> something about URNs as namespace names. -Tim

Thanks, Tim, for taking the effort to put your thoughts into words
in such a well thought out and organized fashion.  A few comments
and questions:

--

Item 1, I fully agree. Well said.

--

In item 2, you talk about "a namespace that makes some assertions about the
syntax and semantics of its content" but no such namespace exists. You are
referring to a document model which uses a single vocabulary grounded in a
single namespace, and the 1:1:1 correlation between namespace, vocabulary,
and model is coincidental -- or even if intentional, does not mean that the
same applies to any other namespace.

A namespace is punctuation. If someone chooses to use a namespace as an
alias or synonym of a vocabulary or document model, then that is poor
practice and is a good example of why there is so much confusion about
what a namespace correlates to.

--

In item 4, you say "[because] namespace names may be "http:"-class URIs,
it is a grievous waste of potential if it is not possible to use the
namespace name in retrieving the definitive material."

While I do agree that it is good for the purpose, significance, or
simply historical use of a given namespace to be clearly documented and
for such information (as for all useful information) to be web-retrievable,
that does not necessarily mean that an http: URL should necessarily be
used as the namespace URI and that the documentation about that
namespace be HTTP GETable via that namespace http: URL.

There are other ways to associate information with a URI (any URI, not
just an http: URL) and other (both real and conceivable) ways to retrieve
such information in a Web context. Just because we have a hammer (HTTP)
does not mean that everything should remain a nail (http:).

Rather, we should work on ways of making knowledge associated with any
arbitrary URI efficiently accessible in a global manner.

Can HTTP with http: namespaces be made to work today? Sure. Will that
meet all of our needs onwards into the future? Probably not.

There are many and varied reasons to use URI schemes other than http:
for namespace URIs (and for other applications as well) and we should
not adopt short term solutions as official web archtecture which will
discriminate against non-http: URI schemes in the future.


Also in item 4, you say "when you use something whose most common
application is retrieval, and you use it to identify something which has
supporting definitive material, it is wilfully perverse not to connect the
retrieval function with the supporting material." which I both agree
with, and also consider to be a good argument for not using 'http:' URIs
for *anything* which is not intended to be HTTP GETable, including
abstract or non-digital resources, vocabulary terms, etc. etc. This is
a very nice argument for URPs ;-)

--

Item 5: I agree fully that namespace URIs should not be relative. I would
go further and suggest that namespace URIs should not be URI references
either -- but that's not core to this particular discussion, really.

(BTW, your reference link gives a 404 error...)

--

You say in item 6: "URNs are not effectively usable in the general
population for retrieval of resources, URNs are not appropriate for
use as namespace names." yet one very good reason for not using
an http: URL as the namespace URI is due to the well known fragility
of location-specific URLs.

[and please, folks, no pointers to the all too well known "Cool URLs
don't change" document, eh? ;-) While that certainly expresses some
folks' views, and has some good points, it's certainly not a silver
bullet to the URL fragility criticisms]

Thus, while it is true that transparent, automated retrieval of URN
denoted resources still has not become commonplace, that seems a
rather weak and short sighted reason for excluding URNs as valid
namespace URIs.

Furthermore, you seem to presume that a "namespace document" is
the only, or even preferred way to associate knowledge with a
given namespace. As pointed out below, knowledge about a given
namespace may be expressed (and likely will be expressed) outside
the scope of control of a single particular "namespace document"
and thus a mechanism which handles open, multiparty expression
of knowledge (e.g. RDF) is a more optimal candidate for recording
and accessing namespace associated knowledge.

--

In item 7 you say "basic definitive material usually consists of
syntax constraints on *THE* markup vocabulary identified by a namespace"
(emphasis added).

Well, while one could consider all terms ground in the same namespace
a single vocabulary of sorts, it is not necessarily a functionally
distinct markup vocabulary designed for a particular application.

While most namespaces host only one functionally distinct vocabulary,
there could be, in fact, numerous separate, possibly intersecting,
functionally distinct vocabularies grounded in the same namespace,
thus there is no absolute 1:1 correlation between namespace and
markup vocabulary. 

Furthermore, each of those functionally distinct
vocabularies would have their own discriptive information, not
specific to the namespace itself, but to each vocabulary, therefore
at most, the namespace would simply be associated with each such
vocabulary and not with any documents describing the vocabularies
themselves.

Furthermore, each of those vocabularies may be used by one or
more document models, and each document model would have its
own documentation not specific to the vocabulary itself, but
to the document model.

Thus, what we really need are URIs for functionally distinct
vocabularies (namespace URIs are not suitable) and URIs for
specific document models (namespace URIs are not suitable)
and a generic solution for associating descriptive resources
(schemas, prose, software components, etc.) with specific
vocabularies, document models, etc. independent of HTTP (though
with the presumption that eventually, most if not all of the
actual digital resources in question will be mapped to some
http: URL for actual retrieval and use).

We need a solution that takes into account the following facts:

   Namespace URI != Vocabulary URI
   Namespace URI != Document Model URI
   Namespace URI != Software Component URI

   Namespace       N:N  Vocabulary
   Vocabulary      N:N  Document Model
   Document Model  N:N  Schema
   Document Model  N:N  Software Component

   URI != 'http:' URL

A note on the N:N relations:

  A functional vocabulary may have terms grounded in different
  namespaces, and a given namespace may host multiple functional
  vocabularies.

  A document model may utilize multiple vocabularies, each grounded
  in a different namespace, and a given functional vocabulary may
  be used by multiple document models.

  A document model may be defined by mulitple schemas, and one
  schema (excluding DTDs) may define multiple document models.

  A document model (or vocabulary) may be supported by multiple
  software components and/or implementations and a single
  software component and/or implementation may support multiple
  document models (or vocabularies).

While short-term approaches such as RDDL may help us limp along
for awhile until the more generalized solution is achieved, it
should not be considered a suitable candidate for inclusion as
part of the web architecture proper and its use should not deflect
efforts and focus on finding/achieving a proper solution for these
issues.

--

In item 9, I agree that knowledge associated with a namespace
(if any) is a collection not a single resource and thus whatever
mechanism is used to associate that knowlege with the namespace
should function similarly to a "directory". However...

Namespace "documents" can only provide contextual information about
the functional vocabularies grounded in that namespace, no more.
Subsequently, each vocabulary may have "documents" which may relate
which document models utilize that vocabulary, and subsequently
each document model may have "documents" which relate which schemas,
sofware components, test suites, etc. may be provided for that
document model, etc. etc. recursively.

The 1:1:1 correspondence between namespace, vocabulary, and
document model is both artificial, not reflected in real world
usage, and far to constrained to be widely useful or scalable over
the long term.

Finally, the relations from namespace to vocabulary, from vocabulary
to document model, from document model to schema, etc. are likely
to be inferential, not explicit. Just as a reused component in a
modular archtecture does not track its parents (which would be
a management nightmare) the minter of a given namespace may not
be aware of all of the vocabularies grounded in that namespace
(all issues of rights and authority aside), or the author of a given
vocabulary may not be aware of all document models based on that
vocabulary, nor may the author of a document model be aware of all
schemas which define that document model, etc. etc.

What is needed is a solution such as RDF which allows schemas to
state which document models they define. Document models to define
which vocabularies they use. Vocabularies which reflect which
namespaces they are grounded in (automatically of course by namespace
prefix). And -- are you ready -- document instances to state which
document models they conform to! Finally, in addition to all of that
relational knowledge, we then, of course, need to know where we can
retrieve the various digital resources equating to or describing
all of those architectural components. But the role of namespace URIs
in all of this is very, very minimal and even insignificant IMO.

The atomic functional components in the above scenario are functional
vocabularies, not namespaces. Any 1:1 correspondence between some
vocabulary and a namespace URI is just a coincidence, not a feature of
the architecture.

RDDL just doesn't capture the reality of these relationships, particlarly
their hierarchical/recursive structure, and 'http:' URLs only come
into the picture when you need to get a specific resource -- not as
a fundamental key to identifying resources or for defining and utilizing
their inter-relational knowledge.

--

Item 11: I certainly can agree that accessibility of knowledge is very
very important to empowering web users in many ways -- but as outlined
immediately above, I don't see namespace URIs as the proper focal point
for organizing such knowledge. It's is just one small piece of the
solution (and a nearly irrelevant, non-functional piece at that) not the
foundation of the solution.

The foundation of the solution should be the globally valid and consistent
denotation of resources by URI and the ability to describe those resources
by associating knowledge with their URI and retrieve knowledge about those
resources by their URIs.

We need to account for the big picture, not just one single use case
(e.g. RDDL + 'http:' namespaces).

--

Item 12: Human-readable technical documentation is most definitely
an important component of the development and use of web applications in
general, but it is not just about what a namespace denotes (since, of
course, a namespace denotes nothing ;-) but that documentation does not
actually describe the namespace, but describes vocabularies, document
models, schemas, software components, style sheets, etc.; none of which
are equivalent to any specific namespace.

Thus, I certainly agree with your sentiments here, but only because they
apply to much broader scope than just this namespace issue. I don't see
them, however, as compelling reasons for either the existence of
namespace documents themselves nor for http: URLs as namespace URIs.

--

Item 14: Agreed. Though this follows from the fact that namespaces
do not equate to either a specific vocabulary nor to a specific
document model -- and of course, even if they did, one could define
the same document model in various schema languages, so it wouldn't
make sense anyway for a namespace URL to resolve to a single schema
instance.

--

In summary, I find sum of your arguments to be very sound and valid
reasons why we need an efficient, scalable, open (not author controlled),
and global directory/registry solution by which we can define the
identities of resources and their functional relationships in a formal
manner so that both machines and humans can discover and utilize that
knowledge effectively.

But http: URLs and RDDL are not that final solution (even if they will
offer some needed, albeit limited, utility in the interim).

Regards,

Patrick

--
               
Patrick Stickler              Phone: +358 50 483 9453
Senior Research Scientist     Fax:   +358 7180 35409
Nokia Research Center         Email: patrick.stickler@nokia.com