W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 1997

[Fwd: draft-daviel-metadata-link-00.txt]

From: Larry Masinter <masinter@parc.xerox.com>
Date: Fri, 16 May 1997 23:55:09 PDT
Message-ID: <337D564D.19EC@parc.xerox.com>
To: w3c-dist-auth@w3.org
Looks pretty relevant to me.
 

Larry
--
http://www.parc.xerox.com/masinter

attached mail follows:


I have submitted
http://vancouver-webpages.com/ml/draft-daviel-metadata-link-00.txt
which suggests a code of practice using Link relationships with existing 
HTTP/1.0 servers and HTML 2.0 parsers  to associate metadata
with non-HTML resources. I have tried to address most of the issues
raised (apart from "forget it; it'll be in HTTP/1.2").

Basically, the concept is to include a Link header
  Link: <http://some.org/some-jpg.html>; rel="META" ; scheme="DC"
in response to a request for a resource which cannot embed metadata
with an optional reverse link
  Link: <http://some.org/some.jpg; rev="META" ; scheme="DC"
from the metadata to the resource.

Issues:

  Timeframe - Now. No server code or standards changes (but see scheme).

  Lying Metadata (spider bait) - Not addressed, same concerns as 
    fulltext indexing (or using snowboarders to advertize beer).

  Metadata Spoofing - forward links given priority over reverse links.  

  Metadata Structure - If a metadata format exists which does not
     support hyperlinks, it can be referenced using the HTTP header.

  Large Metadata - Only agents requiring metadata need request it.
    Agents need request only relevant metadata.

  HTML Equivalence - Since many authors have no access to HTTP headers,
    it is useful to define equivalent actions in HTML. Unfortunately,
    only the reverse link from HTML metadata or fulltext description
    to non-HTML resource is available. This causes problems
    of metadata spoofing, which may be solved simplistically
    by giving a higher priority to metadata whose URL best matches
    that of the resource. This is potentially a concern with
    other reverse link schemes such as DC.IDENTIFIER.

  Metadata encoding - The metadata is transported in its native 
    8-bit-clean format. There is no need to encode or encapsulate it.

  Multiple Schemes - It may be desirable to register a resource in
    more than one scheme. I suggest using an explicit scheme tag.
    Another possibility is to append the scheme to the relationship,
    e.g. REL="META.DC"  Specifying an explicit scheme may break
    current HTML DTD.

  Compatability with future transport  - nothing precludes 
    making metadata available by other methods (GETMETA request, 
    content negotiation, PICS), as they  become more widely available.

Why all these lists ? Well .. it's about metadata, it concerns
indexing agents, and it uses HTTP headers. Apologies for duplicate mail.

Andrew Daviel 
TRIUMF & Vancouver Webpages
Received on Saturday, 17 May 1997 03:00:26 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:42 GMT