[Wikitech-l] [gsoc] splitting the img_metadata field into a new table

2010-05-28 Thread bawolff
Hi all, For those who don't know me, I'm one of the GSOC students this year. My mentor is ^demon, and my project is to enhance support for metadata in uploaded files. Similar to the recent thread on interwiki transclusions, I'd thought I'd ask for comments about what I propose to do. Currently me

Re: [Wikitech-l] [gsoc] splitting the img_metadata field into a new table

2010-05-28 Thread church.of.emacs.ml
Hi bawolff, thanks for your work. I'm not very happy about the name "metadata" for the table. As far as I understand it, this is about file metadata. "metadata" suggests it contains information on pages (e.g. statistics). Please consider using a name that contains 'file', e.g. file_metadata. Than

Re: [Wikitech-l] [gsoc] splitting the img_metadata field into a new table

2010-05-28 Thread bawolff
On Fri, May 28, 2010 at 10:12 AM, church.of.emacs.ml wrote: > Hi bawolff, > > thanks for your work. > I'm not very happy about the name "metadata" for the table. As far as I > understand it, this is about file metadata. "metadata" suggests it > contains information on pages (e.g. statistics). > Pl

Re: [Wikitech-l] [gsoc] splitting the img_metadata field into a new table

2010-05-28 Thread Markus Krötzsch
Hi Bawolff, interesting project! I am currently preparing a "light" version of SMW that does something very similar, but using wiki-defined properties for adding metadata to normal pages (in essence, SMW is an extension to store and retrieve page metadata for properties defined in the wiki -- l

Re: [Wikitech-l] [gsoc] splitting the img_metadata field into a new table

2010-05-28 Thread Michael Dale
More important than file_metadata and page asset metadata working with the same db table backed, its important that you can query export all the properties in the same way. Within SMW you already have some "special" properties like pagelinks, langlinks, category properties etc, that are not sto

Re: [Wikitech-l] [gsoc] splitting the img_metadata field into a new table

2010-05-28 Thread Markus Krötzsch
(This gets a little bit off the topic, but it should still be helpful for the current discussion. But if we want to discuss a more general data management architecture for MW, then it might be sensible to make a new thread ;-) On Freitag, 28. Mai 2010, Michael Dale wrote: > More important than f

Re: [Wikitech-l] [gsoc] splitting the img_metadata field into a new table

2010-05-28 Thread Neil Kandalgaonkar
On 05/28/2010 08:03 AM, bawolff wrote: > Hi all, > > For those who don't know me, I'm one of the GSOC students this year. > My mentor is ^demon, and my project is to enhance support for metadata > in uploaded files. Similar to the recent thread on interwiki > transclusions, I'd thought I'd ask for

Re: [Wikitech-l] [gsoc] splitting the img_metadata field into a new table

2010-05-29 Thread Platonides
Since you are storing in the db the metadata of the images, try to make the schema able to store metadata coming from the page, so it can be used to implement bug 8298 or extensions like ImageFilter. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedi

Re: [Wikitech-l] [gsoc] splitting the img_metadata field into a new table

2010-05-31 Thread bawolff
I'm going to use this message to respond to several people with this email, hopefully it doesn't become confusing. Markus wrote: [snip] >(1) You use mediumblob for values. I'll be honest, I chose a type at random for that field. It needed to be long since it should be able to store rather long st

Re: [Wikitech-l] [gsoc] splitting the img_metadata field into a new table

2010-05-31 Thread Alex Brollo
2010/5/31 bawolff > > I'm going to use this message to respond to several people with this > email, hopefully it doesn't become confusing. > Since you're managinf EXIF data, consider too the possibility to *add* to them some relevant Commons: metadata (name of the File: page, copyright, catego

Re: [Wikitech-l] [gsoc] splitting the img_metadata field into a new table

2010-05-31 Thread bawolff
Hi Alex. Thats actually on my list of to do if I have time. Building a metadata editor for files on the wiki (probably in the form of an extension) would be in phase 2 of my project. (In my project proposal it was on the list of things to do if I have extra time). Cheers, bawolff On Mon, May 31,

Re: [Wikitech-l] [gsoc] splitting the img_metadata field into a new table

2010-05-31 Thread Niklas Laxström
On 31 May 2010 14:14, bawolff wrote: > I'm going to use this message to respond to several people with this > email, hopefully it doesn't become confusing. > Hmm, I like the idea of using the serialized blobs generally, and then > exposing some special few interesting properties into another tabl

Re: [Wikitech-l] [gsoc] splitting the img_metadata field into a new table

2010-05-31 Thread Roan Kattouw
2010/5/31 Niklas Laxström : > I tried to use page_props once. I did end up using my own table, since > the parser thinks it owns the page_props table and when page is parsed > it happily deletes all values stored in page_props it doesn't know > about. > The parser does indeed own the page_props tab

Re: [Wikitech-l] [gsoc] splitting the img_metadata field into a new table

2010-05-31 Thread bawolff
On Mon, May 31, 2010 at 7:04 AM, Roan Kattouw wrote: > 2010/5/31 Niklas Laxström : >> I tried to use page_props once. I did end up using my own table, since >> the parser thinks it owns the page_props table and when page is parsed >> it happily deletes all values stored in page_props it doesn't kn

Re: [Wikitech-l] [gsoc] splitting the img_metadata field into a new table

2010-06-01 Thread Ilmari Karonen
bawolff wrote: > > However, if I do implement a new table as part of this, it will > probably use page_ids to identify the image - I don't see any reason > to artificially restrict it to just the file namespace. Do remember that we'll also want to store metadata for old versions of images. And

Re: [Wikitech-l] [gsoc] splitting the img_metadata field into a new table

2010-06-01 Thread bawolff
Yes, I'll definitly keep that in mind. Currently I'm thinking that for deleted images and old versions of images I'll keep all the metadata inside img_metadata as serialized php, since most of the use cases for having metadata in a different table really only apply to the current version of images.