Re: Opacity and resource metadata (was Re: proposed TAG issues: uniform resource version info and access of resource metadata

On Tue, 26 Nov 2002, Mark Baker wrote:

> ...
> I'd suggest that asserting the relationship between those resources
> would best be done with a triple, rather than naming conventions.  If
> done with an HTTP header, you might get these headers in a response to a
> GET or HEAD on http://www.w3.org/TR/1998/REC-xml-19980210;
>
>   HTTP/1.1 200 Ok
>   Metadata: http://www.w3.org/TR/1998/REC-xml/meta.rdf
>   Up-to-date: http://www.w3.org/TR/1998/REC-xml
>
> Note that you can run out and write up an I-D to define these headers
> right now if you want to; Web architecture already supports this form
> of extension.  IMO, I don't think this is anything requiring TAG
> attention.

This is true. In fact, no naming convention, nor HTTP extension to explain
version information would be required if there was a common agreement how
to refer to metadata of a declared by a resource in the first place (and
thus the statement "I'm a version resource of [2]" would simple be one
part of [1]'s metadata). The idea of placing pointer to the uniform
metadata access point to HTTP header sounds a reasonable technical
solution to me, but the common agreement is the thing I'm really looking
for.

In other words, the point that I'm trying to make is that if we all use
our _own_ ways to give references to our metadata (that's what we're doing
today), we face great difficulties in practise. You use "Up-to-date:", I
use "Version-controlled-resource:", Zaphney uses element <meta> in the
content, etc. If there was a clear, W3C-endorsed recommendation about
which policy to follow, making SW/WS applications would simplify a great
deal (a uniform reference to "all" metadata declared by a resource, i.e.,
a single access point where to look metadata from). If WebDAV+DeltaV is
(will be) such policy, it would be nice if it was clearly stated
somewhere.

I bet these issues (and priorities) are something publishers, librarians,
archiving organisations etc. would have something worth hearing to say
about!

The reason I'm writing this is that I'm not happy at all with the current
"declare your metadata anywhere you wish" policy.

To conclude:

*********************************************************************
To me, uniformly accessing metadata of resources (again maybe resources, I
know) seems as important as accessing resources themselves (next
generation Web?). And thus something for TAG to consider.
*********************************************************************

What comes to naming conventions, the syntax I used in the example is
somewhat irrelevant: XML-rec example is simply something easy enough to
start the discussion from.

However, I do wish that (parts) of URIs would carry some semantics that
could be checked against the metadata, in addition the mere URI scheme
(etc.). I suggest version information because I find it fundamental.

I know that to some extent this is against to the stated TAG principles
("It is not possible to inspect a URI and determine what resource it
identifies." [6]), see

http://www.w3.org/TR/2002/WD-webarch-20021115/#uri-generalities

However, to me it seems that "Over time, we trust that some URIs will
identify familiar resources, but that trust derives from social behavior,
not the spelling of the identifier" has already happened, e.g., in the
case of W3C specs. Thus in principle, if W3C should choose to state that

	[7] http://www.w3.org/TR/REC-html32

is "deprecated", it  would pose a problem. People associate [7] with a
"recommendation" of HTML 3.2, not simply "a" document (or perhaps I'm
wrong). In addition, W3C effectively forces the above naming conventions
for its' specifications, i.e.

	[8] http://www.w3.org/TR/2001/PR-SVG-20010719

means a "proposed recommendation of SVG, published 2001-07-19" without
actually retrieving the resource. Simple saying e.g. that the above URI
name follows a "rule for easy recall" sounds rather vague to me. In
particular because in the context of "social behavior", "W3C Team will
make every effort to archive its documents and cool URIs don't change" (my
free combination of imprecise W3C quotes).

((Actually this branches into another topic which shouldn't be discussed
here (but I mention it anyway and then shut up ;-) -- It would be great if
W3C introduced a metadata classification system for its deliverables. This
is something QA activity is doing anyway so perhaps this should somehow
included in the process document? [If this thread continues in another
mailing list, I would appreciate if I was informed about it.]))

Thank you for the comments. I believe I have said the little I had to say
about this.


Cheers,

--Ossi

P.S. Even if TAG should not consider this, I'll still sleep like a baby
(wake up every now and then and cry helplessly). ;-)

Received on Wednesday, 27 November 2002 06:02:51 UTC