Re: About metadata (long!)
- From: Christopher Curtis <ccurtis ee fit edu>
- To: David Jeske <jeske home chat net>
- cc: gnome-list gnome org
- Subject: Re: About metadata (long!)
- Date: Wed, 19 Aug 1998 15:56:55 -0400 (EDT)
On Wed, 19 Aug 1998, David Jeske wrote:
> Really? I don't think about it that way at all. The way I think about
> it, we have all this data in files all over which is 'trapped' inside
> the file. Perhaps it's something as direct as the 'size' of the image,
Okay ... you don't mean "size" here, but "resolution". Yes, it would be
handy to have a utility that can extract relevant attributes about a file
(such as the Author field in a Word doc, Image Resolution from a GIF/JPG,
etc.) and store that as metadata.
> perhaps it's something much more indirect like 'who the file is a
> picture of'. (in my mind) the job of Metadata is to provide a
> standardized way to publish this data to the world. In fact, in some
Absolutely. Something that should never happen, though, is that GNOME has
to read the file format itself to find the metadata. Want to see your
computer virtually stop? Run GNOME as root...
> cases it might make sense to have the metadata never 'exist' at all,
> but always be derived from the real file format by the appropriate
> piece of code.
If that is possible, fine. I don't see what this discussion is about...
> I have used OS/2, and I understand exactly what you are talking
> about. That's where I formed my previous statement that "metadata
> should be derived from real data". Let me clarify. When I said that
> metadata should be "standard", I didn't mean that the file would ship
> with the metadata. What I meant is that if you have five different
> image formats you would extract the "image_width" "image_height" and
> "image_thumbnail" in a standard way for all the image types, so that a
> viewer would only need to understand one set of metadata.
Sure - I agree completely. I was just saying that I don't think a TRUE
standard could ever be created. I'm sure several pseudo-standards will
arise (like the <blink></blink> tag) and may eventually become standards,
but if a standard _is_ written, that should (a) not limit user-tags and
(b) realize that MS is going to do someting wholly different and possibly
incompatible when and if they ever get around to an object environment.
Maybe the base OS/2 (metadata) tags would be a good starting point, I
dunno, but I think that is a more superfluous problem than "how do we deal
with this data"?
> > I would think that if you are joining an argument over what does
> > and does not comprise an Object Model Environment (Windoze don't count),
> > you (plural - not *you* specifically) would have some experience in one
> > that already exists.
>
> I agree. Perhaps we should just have everyone list the environments
> they've actually spent noticable time using and/or developing for at
> the top of their email. :)
Hmm. I bit my tongue off with that one. =)
> However, in the computing world as it exists today, we can not trust
> that there is a place for 'metadata' to remain on non-metadata aware
> systems. So people will continue to do what they've done for years,
> put it into the fileformat. I argue that this is fine. As people
I'm not saying it's not, but metadata *inside* the file should not be used
within GNOME. Instead, a utility to extract that data and create
"appropriate" metadata entries should be used.
I would not write a counter-program to insert GNOME metadata into the
fileformat itself, but that's just me. Sounds like trouble.
> Just for reference, another way this would be possible, is if all
> files were SGML. If all files were SGML, then we could have standard
> 'metadata tags' just like HTML has it's META tags. Then we could look
> at the 'author' of any file by looking for the standardized tags. I
> just don't think everyone is going to start using SGML as their
> fileformat any time soon. :)
But what if that metadata is not meant to be public?
--
Christopher Curtis - http://www.ee.fit.edu/users/ccurtis
- System Administrator, Programmer
Melbourne, Florida USA - http://www.lp.org/
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]