Re: Proposed issue: site metadata hook

Yes. It makes a lot of sense.  For example, any page on our site has a 
general human-readable admin page
(which happens to be the URI followed by a comma  ie for 
http://www.w3.org/2003/01/W3COrg.svg see
http://www.w3.org/2003/01/W3COrg.svg,   ).  It would be cool to have an 
RDF metadata page -
which could point to the admin page and other related things.

You just have a convention, that site-specific stuff is put in with the 
root metadata.

Tim

On Tuesday, Feb 11, 2003, at 05:39 US/Pacific, Jeffrey Winter wrote:

>
> Why limit this approach to just site-level
> metadata?  Shouldn't a similar approach be
> adopted to bind metadata to any resource
> under the control of the "publisher"?
>
> I can see how this would benefit an RPC-style
> gateway as a means of (for example) standardizing
> how to obtain a WSDL document, but what about
> REST-style applications where each resource
> may (and probably will) have its own specific
> metadata?
>
>
>
>> -----Original Message-----
>> From: Tim Berners-Lee [mailto:timbl@w3.org]
>> Sent: Monday, February 10, 2003 11:02 AM
>> To: www-tag@w3.org
>> Cc: tag@w3.org
>> Subject: Proposed issue: site metadata hook
>>
>>
>>
>> In the face-face meeting I took an action to write up a proposal for
>> the following potential issue:
>>
>>
>> Proposed Short name:  SiteMetadata-nn
>>
>> Title:   Web site metadata improving on robots.txt, w3c/p3p
>> and favicon
>> etc
>>
>> The architecture of the web is that the space of identifiers
>> on an http web site is owned by the owner of the domain name.
>> The owner, "publisher",  is free to allocate identifiers
>> and define how they are served.
>>
>> Any variation from this breaks the web.  The problem
>> is that there are some conventions for the identifies on websites,
>> that
>>
>>     /robots.txt  is a file controlling robot access
>>     /w3c/p3p is where you put a privacy policy
>>     /favico   is an icon representative of the web site
>>
>> and who knows what others.  There is of course no
>> list available of the assumptions different groups and manufacturers
>> have used.
>>
>> These break the rule.  If you put a file which happens to be
>> called robots.txt  but has something else in, then weird
>> things happen.
>> One might think that this is unlikely, now, but the situation could
>> get a lot worse.  It is disturbing that a
>> precedent has been set and the number of these may increase.
>>
>> There are other problems as well - as well sites are catalogued
>> by a number of different agents, there tend to be all kinds
>> or request for things like the above, while one would like to
>> be able to pick such things up as quickly as possible.
>>
>> If, when these features were designed, there had been a
>> general way of attaching metadata to a web site, it would
>> not have been necessary.
>>
>> The TAG should address this issue and find a solution,
>> or put in place steps for a solution to be found,
>> which allows the metadata about a site, including that for
>> later applications, to be found with the minimum overhead
>> and no use of reserved URIs within the server space.
>>
>> Example solution for feasability
>>
>> A new http tag such as "Metadata:" is introduced into HTTP
>> This takes one parameter, which is the URI of the
>> metadata document.  The header is supplied on response to
>> any GET or HEAD of the root document  ("/"). It may also
>> be supplied on a any other request, including error
>> requests.
>>
>> The Metadata document is conventionally written in RDF/XML.
>> It contains pointers to all kinds of standard and/or proprietary
>> metadata about the site, including for example
>>
>> - privacy policy
>> - robot control
>> - icon for representing the site
>> - site maps
>> - syndicates (RSS ) feeds
>> - IPR information
>> - site policy
>> - site owners
>>
>> The solution only needs to document the hook and the
>> vocabulary to point to metadata resources in current
>> use.  Vocabulary for new applications can be defined
>> by those applications.
>>
>> timbl
>>
>>

Received on Tuesday, 11 February 2003 13:48:18 UTC