Re: Indexing non-HTML objects

Andrew Daviel (andrew@andrew.triumf.ca)
Fri, 2 May 1997 17:26:45 -0700 (PDT) 

On Thu, 1 May 1997, Benjamin Franz wrote:

> > Proposal:
> > 
> >   That the reverse META relationship in an HTML header be used to indicate
> >   that metainformation in the current document
> >   applies to the referenced object, not the current document itself.
> >  
> > 
> >   That the forward META relationship in HTTP (RFC 2068-19.6.2.4) be 
> >   optionally used to indicate the existance of metainformation 
> >   pertaining to a non-text object.
> > 
> >   That the reverse META relationship in HTTP be optionally used 
> >   in an identical fashion to the reverse META relationship in HTML.


> 
> http://www.ics.uci.edu/pub/ietf/html/draft-ietf-html-relrev-00.txt expired
> almost a year ago. It is no longer an active proposal unless a new draft
> has been issued somewhere and I didn't notice. 

Well, I had realized and I don't think there's a new one..


> 
> Regardless - one problem is that your proposal only allows *ONE* object to
> be associated with the meta data in a document and so prevents the
> document from containing meta information for *itself* (or for multiple
> included objects).

That wasn't my intention. HTML (and presumably SGML, XML) documents 
normally include their own metadata.
Or do you mean something like an HTML page with two inline GIFs, both of 
which you want to provide metadata for?

I was thinking of those cases where a major resource (datasheet, academic 
paper, movie) exists as one PDF, PostScript, MPEG etc. file and one wants
to index it using one HTML file, and perhaps define both forward and 
reverse links. Metadata in different schemas for the resource can be 
indicated using a schema qualifier


> So now you need *another* document with links to the
> meta document so you can have a document with non-HTML objects with
> associated meta data.  

Well, yes. Nobody's going to make metadata for an email icon. But if the 
HTML wrapper of a JPEG describes the JPEG, there's no reason it needs 
it's own metadata separate from the metadata for the image. I suppose 
it's a bit of a mess where some users have browser plugins and some have
standalone viewers for VRML, MPEG etc. so that some may see the object as 
an embedded frame and others as a distinct object. However, PDF and 
PostScript documents would probably appear full-screen without a visible 
wrapper.



> Additionally, there is the 'multiple/hostile
> meta-document' problem - how do you resolve multiple meta definitions for
> a single object and/or prevent someone *else* from assigning undesired
> meta information to one of *your* objects? 

Is this different from someone framing your content, or creating a
page with misleading or libellous links to your pages?
One of the proposals (I think) for PICS-ng (or PICS 1.1) is to allow just 
that kind of thing. The metadata is tagged in that case with the 
metadata creator's name (rating service).

It's not so daft in any case to have multiple meta definitions for the 
same object if they have different purposes or schema. One might be for a 
specialist academic broker and one for general Web use, for instance.

> It would probably be better to try for a new HTTP header instead. Then a
> server could send something like:
> 
> Metainfo-Location: URL/URI

Well, yes. But Link exists and has some recommended uses (toc, help) in 
HTML3.2 which people are starting to use. Link + rel/rev seemed to make 
sense.

Andrew Daviel