W3C home > Mailing lists > Public > www-tag@w3.org > February 2003

RE: Valid representations, canonical representations, and what the SW needs from the Web...

From: <Patrick.Stickler@nokia.com>
Date: Mon, 3 Feb 2003 10:52:28 +0200
Message-ID: <A03E60B17132A84F9B4BB5EEDE57957B5FBAFD@trebe006.europe.nokia.com>
To: <julian.reschke@gmx.de>, <www-tag@w3.org>



> -----Original Message-----
> From: ext Julian Reschke [mailto:julian.reschke@gmx.de]
> Sent: 02 February, 2003 23:00
> To: Stickler Patrick (NMP/Tampere); julian.reschke@gmx.de;
> www-tag@w3.org
> Subject: RE: Valid representations, canonical 
> representations, and what
> the SW needs from the Web...
> 
> 
> > From: www-tag-request@w3.org 
> [mailto:www-tag-request@w3.org]On Behalf Of
> > Patrick.Stickler@nokia.com
> > Sent: Sunday, February 02, 2003 5:51 PM
> > To: julian.reschke@gmx.de; www-tag@w3.org
> > Subject: RE: Valid representations, canonical 
> representations, and what
> > the SW needs from the Web...
> >
> > ...
> > > I'm still not sure that I follow you that a RDDL document 
> can't be a
> > > representation of a namespace. If a textual description of a
> > > namespace can't
> > > be used as a representation, what else?
> >
> > But the content of a RDDL document is largely information not
> > inherent in the XML namespace of which it is supposedly a
> > "representation".
> 
> I think this largely depends on what the author puts in, right?

Sure. But I've yet to see any RDDL example (and I've looked at lots)
that is not essentially a description of schemas, stylesheets, and
prose documents which are all different resources from the namespace,
and have seen very few RDDL examples which actually enumerate the
members of the namespace itself, and even then, they include
substantial information about semantics not inherent in the namespace.

So, the purpose and practice of RDDL is to return knowledge that
is not inherent to the namespace. A valid representation of the
namespace itself is a very rare exception, and not the norm.

Now, though it may seem so, I'm not RDDL bashing. I think RDDL like
information is very necessary, and very much agree that such information
should be reasonably easy for folks to get it. It's just the means by 
which one obtains that information that I have trouble with.

> > > Or are you saying that there
> > > actually *isn't* a valid representation for a namespace?
> >
> > No. I would accept an enumeration of names grounded in that 
> namespace
> > to be a valid representation of the namespace (and if folks consider
> > a namespace to be infinite, which technically, I guess it is, then
> > an enumeration of the names in-use or explicitly identified as
> > usable/significant/whatever by the namespace owner).
> 
> I assume that XHTML would be ok? I think that's what RDDL is 
> (or at least
> used to be).

I don't see how this addresses my comment. I'm talking about the
scope of the information embodied in the "representation" as it
pertains to the nature of the resource denoted, not how that
information is encoded.

> > But most/all of a RDDL document says nothing about the namespace,
> > but about other resources in some way related to the namespace.
> > It's like a representation of Paris describing all the cities of
> > Europe because Paris is in Europe.
> 
> I'd say it's like a document saying something generic about Paris, and
> containing links to additional information like shop 
> directories, maps,
> events. Exactly what I'd want it to be.

I'm not talking about links. I'm talking about verbose descriptions of
each and every city. I.e. I would expect that a RDDL document, if encoded
in RDF, would have as the subject of a large majority of statements the 
namespace, not other resources. The representation would describe, or
represent, the resource. Not other distinct resources that are simply
related.

Another example, getting a typical RDDL document as a representation of
a namespace is like getting an image of a map of Europe as a representation
of Paris. The significant excess of information in a RDDL document is
no more an (intuitively) acceptable representation of a namespace than is
the significant excess of information in a map of Europe an (intuitively) 
acceptable representation of Paris.

> > The vocabularies, models, stylesheets, etc. identified and described
> > in a RDDL document are not part of the namespace. They are merely
> 
> Yes.
> 
> > related to the namespace because the utilize names grounded in that
> > namespace, and hence I consider such verbose descriptions of
> > *primarily other* resources in a "representation" of an XML 
> namespace
> > to be a deviation/violation of the Web/REST architecture.
> 
> Again, that depends on what the author puts into the RDDL 
> document, right?

Yes, but this is my point. There is no clear definition of what a
reasonable or valid representation is in terms of the inherent
qualities of the resource. It is so vaguely defined as to allow
essentially arbitrary entities being treated as representations
simply because some human decided to do so.

Now for humans interpreting results in a web browser, perhaps this
is not a big deal. We're used to sifting through garbage on the web.

But even though particular individuals might employ poor practice
and do things that are contrary to the concepts and expectations
of the web architecture -- such as returning dubious entities as
representations of resources of which are intuitively invalid -- for
the W3C to promote such poor practice by sanctioning the treatment
of RDDL documents as representations of namespaces would be very
disturbing.

Certainly the web and SW architecture(s) must allow for some degree
of noise and junk in order to be sufficiently flexible, dynamic, and
scalable for global deployment, but it should be expected that the
key architects and creators of the web and SW would set a good
example and make every effort to uphold the conceptual ideals
underpinning that architecture.

Treating RDDL documents as representations of XML Namespaces is
IMO poor practice and does not reflect the intuitive notion of
a valid representation of a namespace resource. If individuals
wish to employ such a hack, fine, but it should not be considered
an optimal or final solution to making such knowledge easily
and consistently obtainable.

It simply serves to perpetuate the common misunderstandings
regarding the nature and relationships between namespaces,
vocabularies, models, schemas, stylesheets, etc. 

> > ...
> >
> > > > Granted, typical browser users are not used to thinking about
> > > > metadata, but that doesn't mean they would not understand and
> > > > welcome a means to ask a server "Tell me about this thing"
> > > > rather than "Show me this thing".
> > >
> > > Well, they can do that right now.
> > >
> > > What's not really possible right now is to have metadata for
> > > a resource
> > > (PROPFIND succeeds) with no representation (GET/HEAD fail),
> > > because that's
> > > not really compatible with the underlying model (PROPFIND for
> > > non-collection
> > > resources basically being an extended HEAD method with XML
> > > marshalling).
> >
> > Well, if that's true, then WebDAV definitely fails as a solution
> > to standardized access to resource metadata, since one would expect
> > to be able to use the same solution for all resources, whether or
> > not any representation is available.
> >
> > Pity...
> 
> OK. So how do we expect HEAD to behave when no representation 
> is available?

Well, as it appears that HEAD only returns metadata describing
the representation, and not metadata describing the resource,
then neither HEAD nor PROPFIND are acceptable solutions to this
problem.

It looks like we need something new. Such as a new set of methods,
GET-META, PUT-META, POST-META, which would by definition deal with
metadata describing the resource itself, and would also ideally
by definition accept/return RDF.

Patrick

--
Patrick Stickler, Nokia/Finland, (+358 40) 801 9690, patrick.stickler@nokia.com
 
Received on Monday, 3 February 2003 03:52:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:16 GMT