On Thu, May 10, 2001 at 08:40:18AM -0400, Benjamin Coates wrote:
> >From toad <[EMAIL PROTECTED]>
>
> >It is a real problem because Brandon and others want to use highly
> >descriptive human written metadata, for example the Dublin Core stuff
> >includes several fuzzy fields.
>
> What's the point of attaching this highly descriptive stuff to the file at
> all?
> Wouldn't this belong in an seperate indexing/searching layer? The sort of
> metadata you need in a CHK is stuff like content-type or part-number or
> whatever, that lets you interpret the data you have, not author or keywords or
> subject (that lets you find or categorize the data)
>
> --
> Benjamin Coates
>
>
The point of putting it in the same package is validation. Hard to dispute that
the metadata was meant to refer to the data if it's in the same package.
Perhaps the way to sort this out is to think about separating descriptive stuff
into two categories, one Freenet specific, and one generalized.
Part number and fields like that really only have meaning in the context of
Freenet, once the data payload has left Freenet these descriptions are irrelevant.
This kind of metatdata should live where it makes functional sense for it to be,
the requirements are determined by how the Freenet code needs to use the metadata.
Generalized metadata has meaning outside of Freenet, once the data payload has left
Freenet the metadata is still usefull, and still communicates something about the
data. Content-type is one of these types of description. Where this metadata should
live is much less clear, the requirements are not just determined by what the Freenet
code needs, unless you're just specifying for the convenience of the coders.
Unfortunately, that's where things stand right now. After over a year of flailing
around with this stuff, there is still no agreement on what the requirements are
for the generalized form of metadata. The properties that the generalized form of
metadata will have, like validation, flexibility, etc. will be determined by what's
convenient to code, because there is simply no other guidance.
David Schutt
_______________________________________________
Devl mailing list
[EMAIL PROTECTED]
http://lists.freenetproject.org/mailman/listinfo/devl
