Re: [GNUnet-developers] Keywords with file insertion

[Christian Grothoff]

Sorry for the late reply, I've been busy :-).

On Friday 21 January 2005 16:25, milan wrote:
> Yeah, that's my idea. ;-) GNUnet-GTK does a few keyword extraction, but
> doesn't organise keywords like it should. Indeed, I'm working on a form
> to insert audio easily and to add standard keywords (like ID3 and Vorbis
> comment's Title, Artist, Album, Date...) to the file descriptor in
> GNUnet AFS. This can be done without much problems now, but time. :-) I
> promise you I'll work on it more... See the attached screenshot to have
> an idea of what it can be... and give me your suggestions.

How about not having just those file-specific lists?  Just re-use the set from 
libextractor and make it truly flexible.  GNUnet 0.7.0 will allow meta-data 
for any keyword type supported by libextractor (and of course we can add 
additional categories to LE if necessary).

> So the idea of "<title:>title" was abandoned. I haven't looked really
> how the implementation of the 'tag' in the descriptor's was done, but I
> will do so soon.

I don't think anyone said that.  I still plan to have it in 0.7.0.

> >Yes, this is true. However, if a file would have an additional keyword
> >with it's MD4 then ed2k links could be resolved using the MD4 provided
> >by them.

What we'll do is have say ed2k (or magnet) URIs as keywords and 
(automatically) put a KBlock under that 'keyword'.  Then clients can search 
for those KBlocks and find the meta-data.

> >(because this is computationally intensive, it should never be mandatory)
> >What I would like to see is a proposal for the extra metadata a user
> >might want to add. Using only date is like saying computers will never
> >need more then 300K RAM.
>
> So it could be added to the tag, no ? We should choose if metadata list
> will be flexible (i.e. user can add every kind of data he want's
> manually, like MD4, Genre...) or if we choose a precise list, like
> Vorbis comment's list. What do you think ?

It'll be flexible within the set of available LE categories.  Communicating 
the category as a string would be wasteful (just like the genre in ID3v1 tags 
are just one byte), but with 32 bits for the category we can have pretty much 
all the categories we want.

> The list could be large, to allow many possibilities (user needs are not
> so infinite...).

Right, but that just makes it a challenge to make the UI nice.  For example, 
you could have the UI limit the list automatically if the mime-type is some 
indication as to what is useful. But the basic (GNUnet core) mechanism will 
allow for maximum flexibility.

C