Re: Database example was: The Kesselman/Connoly proposal

A scenario such as the following does not convince.

It remains to be demonstrated, that the relations among namespaces
follow the process and or table structure in the server's data store.
Either the concept-structure implicit in the namespace name is
"universal", in which case the relations known the the recipient - those
implicit in its resolution of validation resources, are unlikely to
mirror the structure of the server database, or the concept-structure is
truly ad-hoc - at the whim of the data source, with any validation
resources provided by it upon request. In which case the namespace names
are arbitrary - so long as uniquely identifying and it is not necessary
to expose any of the structure externally.

Tim Berners-Lee wrote:
> 
> ...
>
> - the database (say) has URI http://internal.example.com/2000/05/foo . When
> asked to render that, the HTTP server will respond with an XML document
> pointing users at the various tables and written using the xHTML namespace.
> (It references the XHTML namespace of course by absolute URI using the one
> in the XHTML spec)
> It makes a link to the employees table as "foo/employees".
> 
> - the namespace for encoding data from the database is (relative to the
> above) foo/ns. When asked to render this by a client understanding XML, a
> document is returned written in the xml-schema namespace. (Referenced by
> absolute URI). foo/ns defines the datatypes of the columns in the database
> and the syntactic constraints for
> the serialization of database data represented in foo/ns.  This allows a
> syntax checking tool to verify that data documents are schema-valid.  It is
> a *represenattion* of the namespace - the bits are returned are not of
> course the namespace itself which is an abstract thing, a resource,
> 
> - the employee table is foo/employees. This is rendered as a an XML table
> with the data encoded in the namespace foo/ns . When asked to render
> employees, the server responds with a document using namespace foo/ns, which
> it refers to using relative URI "ns".
> 
> The server *could* have looked up the original URI with which it had been
> invoked, and use http://internal.example.com/2000/05/foo/ns  but  this would
> be the first time it has to be aware of its own hostname. Further, as the
> namespace is a custom one for this particular database, it is as persistent
> or transient as the data itself. So there is no "persistence" argument for
> using a relative URI.  There is a data management argument for using a
> relative URI.  (This also applies in the case of the same thing being
> written by a human).
> 
> So here we have a one-off namespace made quite automatically by the database
> application. Until and unless the user has made some connection to other
> information, then it stands alone with the data. It is intimately connected
> with the data, they are published together just as an HTML file and an
> embedded image.
>

Received on Friday, 30 June 2000 13:32:40 UTC