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

RE: Proposed issue: site metadata hook

From: Joshua Allen <joshuaa@microsoft.com>
Date: Tue, 11 Feb 2003 13:16:51 -0800
Message-ID: <4F4182C71C1FDD4BA0937A7EB7B8B4C107B70BCF@red-msg-08.redmond.corp.microsoft.com>
To: "Tim Berners-Lee" <timbl@w3.org>, "Jeffrey Winter" <JeffreyWinter@crd.com>
Cc: <www-tag@w3.org>

I like the idea of having a convention for URIs that provide information
about other URIs.  Too bad we can't use ' (the symbol "prime" used to
denote "meta" in Calculus).  So you would have
<http://www.microsoft.com'>, <http://www.microsoft.com''>, etc.

Anyway, please share opinions on the following two questions:

A.  Should the "meta" URL for a URL return *all* metadata for the URL?
What if I want to get just metadata of a certain type?  If I am querying
for robots data, I don't want to get everything else.

B.  Why not let sites return metadata about URLs which they do not own?
In other words, <http://www.microsoft.com'> gives me the *Microsoft*
report of metadata for that URL, but what if I want IBM's report?

> -----Original Message-----
> From: Tim Berners-Lee [mailto:timbl@w3.org]
> Sent: Tuesday, February 11, 2003 10:49 AM
> To: Jeffrey Winter
> Cc: www-tag@w3.org; tag@w3.org
> 
> 
> 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 16:17:38 GMT

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