Re: [namespaceDocument-8] Proposal: "Namespace Document" = RDF

----- Original Message -----
From: "Patrick Stickler" <patrick.stickler@nokia.com>
To: "Patrick Stickler" <patrick.stickler@nokia.com>; "ext Tim Bray"
<tbray@textuality.com>; "WWW TAG" <www-tag@w3.org>
Sent: Monday, February 18, 2002 5:13 AM
Subject: [namespaceDocument-8] Proposal: "Namespace Document" = RDF


>
> In Tim Bray's recent discussion of the namespace issue in
>
> >> http://www.textuality.com/tag/Issue8.html
>
> Tim defines a "namespace document" as whatever one might retrieve
> from an HTTP GET on an 'http:' URL, if such is used as the
> namespace URI, and suggests that the namespace
> document would be a RDDL instance (presumably XML).
>
> I would like to propose an alternative interim treatment which is
> similar in nature to the RDDL approach, and in fact would adopt
> the RDDL vocabulary in its realization, but which would be more
> forward-looking towards a time whtn such knowledge would not be
> tied to HTTP for retrieval and not expressed only in XML, but would
> be accessible by more generalized, transparent means and have an RDF
> foundation.

This is, of course, much more sound.  I understand some folks prefer the
XLINK version, and I don't like to push RDF as Director, but RDF is
appropriate
here, and I hate to think of leaving a legacy of litle RDDL1 > RDDL/RDF
converters
distributed thoughout the data processing world.

> Let us redefine a "namespace document" to be an RDF instance
> (using the RDDL vocabulary, and perhaps other vocabularies as well)
> which provides knowledge *relevant to* the use of the namespace
> but not merly about the namespace itself, alone.

(On principle, I would never prohibit an RDF document from containing
other stuff. It is just too useful to be able to add information about
 arbitrary but relevant things to any RDF document.

For example security or trust information about the various documents
would be relevant but not specifically about the namespace.

> This RDF instance would provide knowledge about any and all
> resources which the owner of the namespace felt may be relevant
> and useful to anyone using any architectural component related
> to that namespace.
>
> Thus, it would describe vocabularies, document models, schemas,
> software components, style sheets, discriptive prose, etc. each
> of which would have URIs distinct from that of the namespace.
>
> The URIs denoting these resources need not be http: URLs, nor
> even URLS or URNs, but can be any class of URI whatsoever.

That is the wonder of URIs, that once you have called one out
you can use any kind.   But best practice will be to use
dereferencable ones.

> And the descriptions about each resource would be specfic to that
> resource, not the namespace, which has no real properties apart
> from punctuation and providing a point of intersection for the
> trully interesting resources described in such an RDF namespace
> document.
>
> Later, in the future, when such RDF knowledge can be retrieved by
> means other than from namespace documents and HTTP, such as via global,
> distributed knowledge registries, and thus not bound to the use of http:
> URLs, the need for such "namespace documents" would dissappear, and
> also all benefit of using http: URLs as namespace URIs -- yet
> applications would already be used to working with such generalized
> knowledge and how it is obtained would remain a triviality.

Still, even though http may morph into new ans splendid forms, the namespace
document
as the result of dereferencing the namespace URI would be special
because it would be publsihed by the owner of that URI and say what thay
owner meant.
Even if the semntic web version of google actually supplied you the answers
in practice.

> Furthermore, such an approach permits applications to maintain
> local knowledge bases about known resources, possibly also caching
> web retrieved knowledge for offline use, or augment that with any
> number of dedicated registries, providing a more flexible,
> scalable knowledge based solution -- hampered only temporarily by
> transparent, global web-accessibility of such knowledge, yet
> architecturally sound both now and in the the future when such
> accessibility issues are resolved.

Indeed, the whole point of using RDFis taht all the processing and caching
and filtering and querying and agglomerating and so on can be done
to it along with all your other data, no new tools required.

> Owners of namespaces not based on http: URLs can still author and
> publish RDF namespace documents -- for installation locally to any
> system using architectural components grounded in that namespace,
> and for future propagation into global registries.
>
> Such an interim solution would meet the immediate needs of specialised,
> constrained HTTP based solutions while facilitiating and encouraging
> work towards a more generalized, long term solution.

When the web started, the centralzied registry approach clearly would not
scale.
Since then we have search engines -- but they are secondary, even though
they scale
disturbingly well.

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

Received on Thursday, 28 February 2002 00:43:47 UTC