> Date: Sat, 12 Sep 1998 18:55:43 -0400
> From: Feuer <feuer@his.com>
>
> The big thing is to really not depend on the presence/support of
> metadata. Here it goes. You have file and its metadata. You transfer
> over net using metadata-unaware program/system. Metadata
> lost. Application opens file. No problem. User edits file, perhaps.
> User hits save. Application realizes there is no metadata.
> Application writes metadata. No problem.
>
> Sure. But in that case, exactly what are you going to be storing in the
> metadata? It has to be information which is can be rederived from the
> main data fork. But in that case, why not just use the information from
> the main data fork and be done with it?
>
> My point was precisely this --- if you restrict yourself to data for
> which it is harmless if the metadata disappears, then there generally
> isn't very useful for the application. There might be a few specialized
> uses for it, but is it really worth all of this effort for a rather
> marginalized uses?
>
> For the desktop, if you want to store information about where on the
> screen the icon should live, then perhaps that would be a valid use of
> metadata --- but that's a desktop use, not an application use.
>
> But as Alan Cox has pointed out, information about what icon to use, and
> where on the desktop the icon should live, or even which application to
> use when opening a file (emacs or vi?!?), etc. really should be stored
> on a per-user basis. Furthermore, the user should be able to modify or
> store this information for files for which the user doesn't have write
> access. You also don't want to have different users being able to
> modify this information for other users. All of this means that it's
> probably best to store all of this information in a central database or
> dotfile in the user's home directory.
>
> So it's not clear that file metadata would be useful for desktop
> systems, either!
>
> This brings me back to my first observation --- it's not at all clear
> how useful file metadata really is. Could one of the advocates of file
> metadata give me an actual proposed application which could profitably
> use it?
>
> - Ted
Your argument has actually clarified my thoughts on the matter :). What
sorts of metadata might I want........ The answer depends on whether a
metadata format eventually becomes standard. I give you two lists.
Immediate
---------------------
file type (MIME type or similar)
creator of file
things the file depends on (particularly for apps)
The compression type, if any. (possibly subsumed under file type, but maybe
not)
Date file created, date file contents created (difference in the case of
copy, tar, gzip, etc)
Once metadata is standard (if ever)
Eventually
---------------------
Brief description of purpose/content of file (summary)
File types an application can handle (for shell/desktop stuff, etc.)
I'm sure other things as well, don't know what for sure.
I think metadata can be useful. One point I stated unclearly was the matter
of depending on it. If it becomes fairly standard (some Unices, Mac,
windows would be enough), it can be used more. I was saying that if Linux
makes metadata, those who write apps certainly will not want to depend on
metadata to function. If it eventually is standard, it can be used more.
There was another point you made: You said that if the information can be
derived from the main data fork, it need not be stored as metadata. First
off, not all information which can be recovered is derivable from the main
data fork. For example, if I have a TIFF image, and I lose the metadata
file type, my windowing system etc. will no longer know it is an image. If
I attempt to open it (by double-click or whatever), nothing will happen.
But I know that it is an image, since I can understand its filename and
perhaps even remember it. When I open it with an image editor and re-save
it, certain metadata, including filetype, will be recovered. I can even
reconstruct metadata on the command line. for instance:
modmeta filetype=image/TIFF
modmeta creator=David\ Feuer
I recommend looking at the Berlin development mailing list archive for some
discussions on this topic. See www.berlin-consortium.org.
David Feuer
feuer@his.com
david@feuer.his.com
dfeuer@binx.mbhs.edu
dfeuer@morse.usno.navy.mil
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/faq.html