Member
Developer
Member
It might be neat to have something like a simple text box on the frontpage that allows you to search via tags and then for smart-albums you could have a seperate page inwhich you could "create" the smart-album, then click "Next" and it'll bring up another page that displays all the photos that you've defined for it to show...just an idea.
Member
Member
About tagging - another word for tags could be keywords?
IPTC already has keywords. Why not use this? I would really prefer full support for IPTC over an extra tagging function.
BTW - I really do not understand this craze about tagging. If someone wants to add keywords to their pictures, I can understand it. But to have tagging in a forum like this that run on SQL is not too understandable. If the post I am making here do not contain everything that is worth searching for, why bother writing it?
Oh, well...... That is just me and my opinion. I do not mind if anyone else has a different opinion as long as they do not force it on me.
IPTC already has keywords. Why not use this? I would really prefer full support for IPTC over an extra tagging function.
BTW - I really do not understand this craze about tagging. If someone wants to add keywords to their pictures, I can understand it. But to have tagging in a forum like this that run on SQL is not too understandable. If the post I am making here do not contain everything that is worth searching for, why bother writing it?
Oh, well...... That is just me and my opinion. I do not mind if anyone else has a different opinion as long as they do not force it on me.
Member
Member
Tristan is working very hard on new features as the roadmap develops. Tags are in the list, but he also works very hard to make sure each version is very well-coded and bug-resistant (I won't say bug-free - since we're all human). He's still working on getting the wiki back up, so the roadmap is currently on holiday, but I think tags were due somewhere around v2.0 or so. I think before that he's going to have a plugin API so that we can all make our own plugins much easier, which may be right up your alley.....
Member
Last night I was able to get some simple tag stuff working. As I have it, pictures have tags, and I extended the image class to show the tags for a picture. Adding the tags through the interface (right now I was testing them by adding them to the database directly) will come next, but since it will behave very much like the image description code, the interface part should be pretty easy.
As for tagging/keywords/taxonomy/folksonomy, some reading to start:
http://neosmart.net/blog/2007/the-need-for-creating-tag-standards/
So, out of curiosity, what would people like to see in a zenphoto tagging system? There are a couple design choices I would think need to be made, depending on what people really want/need:
-Space or commas to separate tags? Something configurable? (This seems like a little thing, but depending how configurable the code has to be does affect its complexity)
-Limited character set? This could be useful in that tag-based URLs would be meaningful.
-Flat, bundles (like del.icio.us), full tree hierarchy of tags, or something configurable? If not flat, can tags be duplicated and still be the same tag, or are they different? Are the non-leaf nodes searchable and visible to the site viewers, or are they just or organise the tagging process?
As for tagging/keywords/taxonomy/folksonomy, some reading to start:
http://neosmart.net/blog/2007/the-need-for-creating-tag-standards/
So, out of curiosity, what would people like to see in a zenphoto tagging system? There are a couple design choices I would think need to be made, depending on what people really want/need:
-Space or commas to separate tags? Something configurable? (This seems like a little thing, but depending how configurable the code has to be does affect its complexity)
-Limited character set? This could be useful in that tag-based URLs would be meaningful.
-Flat, bundles (like del.icio.us), full tree hierarchy of tags, or something configurable? If not flat, can tags be duplicated and still be the same tag, or are they different? Are the non-leaf nodes searchable and visible to the site viewers, or are they just or organise the tagging process?
Developer
Hey Alex, that sounds great. Make sure you're using fresh SVN code for development, it's quite stable pre-1.0.8 right now.
Also, how are you storing tags? Separate database table? Referencing by Ids on each image? And is there a many-to-many mapping table, or is it a list of ids in an image field?
Also, I imagine it being quite different from the image description code. You need a text box, yes, but it also needs to have a tag list that gets updated, and preferably by AJAX of course. Some work to be done there.
Also, how are you storing tags? Separate database table? Referencing by Ids on each image? And is there a many-to-many mapping table, or is it a list of ids in an image field?
Also, I imagine it being quite different from the image description code. You need a text box, yes, but it also needs to have a tag list that gets updated, and preferably by AJAX of course. Some work to be done there.
Member
> Hey Alex, that sounds great. Make sure you're using fresh SVN code for development, it's quite stable pre-1.0.8 right now.
Just set up SVN this morning. Did you get my email?
> Also, how are you storing tags? Separate database table? Referencing by Ids on each image? And is there a many-to-many mapping table, or is it a list of ids in an image field?
A many-to-many table mapping the images table to a tags table. The SQL ends up more complex than just storing text on the image, but it means the DB can do all sorts of snazzy selects based on tags. I already tested out some statements that do stuff like "all images including tag1 and tag2 and don't have tag3", and it worked great.
> Also, I imagine it being quite different from the image description code. You need a text box, yes, but it also needs to have a tag list that gets updated, and preferably by AJAX of course. Some work to be done there.
As I have it, the getTags() method on the image class just returns a space-separated string, and the intent is the set method will also just take a string, so for now the web-side interface can work just like description field. To that I'd eventually want to add a del.icio.us-like tag list you can just click on and have it build the string for you. The set method will then adjust the tags and mapping in the DB as needed.
Just set up SVN this morning. Did you get my email?
> Also, how are you storing tags? Separate database table? Referencing by Ids on each image? And is there a many-to-many mapping table, or is it a list of ids in an image field?
A many-to-many table mapping the images table to a tags table. The SQL ends up more complex than just storing text on the image, but it means the DB can do all sorts of snazzy selects based on tags. I already tested out some statements that do stuff like "all images including tag1 and tag2 and don't have tag3", and it worked great.
> Also, I imagine it being quite different from the image description code. You need a text box, yes, but it also needs to have a tag list that gets updated, and preferably by AJAX of course. Some work to be done there.
As I have it, the getTags() method on the image class just returns a space-separated string, and the intent is the set method will also just take a string, so for now the web-side interface can work just like description field. To that I'd eventually want to add a del.icio.us-like tag list you can just click on and have it build the string for you. The set method will then adjust the tags and mapping in the DB as needed.
Developer
Member
Got tags working. The editing interface is just a string, but that'll do for now. The backend gets all updated with change -- it handles adding and removing tags.
Now on to some tag-based browsing!
Now on to some tag-based browsing!
Member
Heya Tristan,
I know you've been busy with 1.0.8, but when you get a chance:
I've been able to implement a new tagset class -- given one or more tags, it returns just the images with all those tags. I've got pretty much full end-to-end pieces in place, from class-tagset.php, to changes in the controller and template functions through to a new template page representing the browse-by-tag page: Enough that I can put in a URL of /gallery/tagset/tag1%20tag2 and get back a page listing the filenames of the images tagged with both tag1 and tag2.
My sticking point now is the Image class -- as it stands, I believe it needs to be created with a populated Album object, which I don't currently have in this album-free context. I could create one, I think, but that seems like a fair bit of extra overhead if it's not needed. Given the current roadmap, is that likely to change? It seems that for Groups, Dynamic Folders, search results, etc., you'll want to be able to create Images without creating the album.
I don't want to go in a vastly different direction here, since that would make future integration, if desired, much more difficult. For now, I'll try creating an Album object and see if that does the trick.
I know you've been busy with 1.0.8, but when you get a chance:
I've been able to implement a new tagset class -- given one or more tags, it returns just the images with all those tags. I've got pretty much full end-to-end pieces in place, from class-tagset.php, to changes in the controller and template functions through to a new template page representing the browse-by-tag page: Enough that I can put in a URL of /gallery/tagset/tag1%20tag2 and get back a page listing the filenames of the images tagged with both tag1 and tag2.
My sticking point now is the Image class -- as it stands, I believe it needs to be created with a populated Album object, which I don't currently have in this album-free context. I could create one, I think, but that seems like a fair bit of extra overhead if it's not needed. Given the current roadmap, is that likely to change? It seems that for Groups, Dynamic Folders, search results, etc., you'll want to be able to create Images without creating the album.
I don't want to go in a vastly different direction here, since that would make future integration, if desired, much more difficult. For now, I'll try creating an Album object and see if that does the trick.
Developer
Ah, but your images will have albums technically, since they will still always reside in folders, so semantically it still makes sense--
What would make more sense is for Albums to be a subclass of Group, and Tagset to also be a subclass of Group, then for an image to be a member of a Group instead of an Album. Then you could have images in albums explicitly, or in Tagsets, or in Searches, or whatever.
This would, I believe, have some consequences for the Image class as you say. First, the Image needs to store the whole path to itself, independent of the group it happens to belong to. Not too hard.
I think that's the ideal solution, and something for 1.1 or 1.2. I like where that's going, it would add a whole new level of flexibility to the already flexible Zenphoto. :-) I will do it that way, as far as I know now, so you can go ahead and instantiate Album objects in your code now just to get the whole path, with the idea that you may get rid of them later when that's all contained in an Image.
Cool :-) Thanks for helping me think that through.
What would make more sense is for Albums to be a subclass of Group, and Tagset to also be a subclass of Group, then for an image to be a member of a Group instead of an Album. Then you could have images in albums explicitly, or in Tagsets, or in Searches, or whatever.
This would, I believe, have some consequences for the Image class as you say. First, the Image needs to store the whole path to itself, independent of the group it happens to belong to. Not too hard.
I think that's the ideal solution, and something for 1.1 or 1.2. I like where that's going, it would add a whole new level of flexibility to the already flexible Zenphoto. :-) I will do it that way, as far as I know now, so you can go ahead and instantiate Album objects in your code now just to get the whole path, with the idea that you may get rid of them later when that's all contained in an Image.
Cool :-) Thanks for helping me think that through.
Developer
And of course I'll be wanting to look at your code when you're done :-)
Extensible groups... heh, I love the idea. Think of all the ways you could combine images from different places together... and then operate on them in common ways. Very very cool....
It brings up more technical problems though, like what if the database isn't current or perfectly matched to the filesystem... you'll have trouble forming groups from the filesystem as albums currently do. You need that database synchronicity that ZP's not designed for yet (and for good reason-- it's currently based on the filesystem with the database as a metadata storage facility only, not as a data or query source)... but that could be improved with incremental folder scans and garbage collecting (eg: not all at once, just in parts, like GC a folder when an album is loaded, or pre-load traverse all folders when the gallery is loaded, or garbage collect every 30 minutes, etc. There are ways we could make it work...)
Okay, just thinking out loud. Tell me what you think! Thanks.
Extensible groups... heh, I love the idea. Think of all the ways you could combine images from different places together... and then operate on them in common ways. Very very cool....
It brings up more technical problems though, like what if the database isn't current or perfectly matched to the filesystem... you'll have trouble forming groups from the filesystem as albums currently do. You need that database synchronicity that ZP's not designed for yet (and for good reason-- it's currently based on the filesystem with the database as a metadata storage facility only, not as a data or query source)... but that could be improved with incremental folder scans and garbage collecting (eg: not all at once, just in parts, like GC a folder when an album is loaded, or pre-load traverse all folders when the gallery is loaded, or garbage collect every 30 minutes, etc. There are ways we could make it work...)
Okay, just thinking out loud. Tell me what you think! Thanks.
Member
I rather like the idea of Album, Tagset, SearchResult, etc being subclasses of Group. Group is just a collection of Items, and the subclass can determine how to populate it.
I say Item, since if Image is a subclass of Item, then so could Video, DownloadableFile, or other individual item classes that people want -- I, for example, know I want to have an Image-type class that behaves differently on the tag context it is being viewed in. There would be a lot of options for extensibility, perhaps there could be even HTML items, etc.
Now, what if Group is a subclass of Item (or at least there is a GroupItem that is a subclass of Item that represents a Group)? Now your Group can include both images and groups -- so you can have subalbums, search results that can return folders or things like saved searches, etc. Even the gallery index can be subclass of Group (with the default view being root-level albums).
If you went that route (or even if you didn't), I'd also be very tempted to pass the URL processing to those classes -- let the URL determine the object the send the next part of the URL to. My experience so far, limited as it is, is that adding new classes means dealing with the URL handling (a la rewrite_get_album_image(), etc) a lot more than is fun. If the URL matches the object structure (and not the physical structure), then that should be a whole lot easier.
I say Item, since if Image is a subclass of Item, then so could Video, DownloadableFile, or other individual item classes that people want -- I, for example, know I want to have an Image-type class that behaves differently on the tag context it is being viewed in. There would be a lot of options for extensibility, perhaps there could be even HTML items, etc.
Now, what if Group is a subclass of Item (or at least there is a GroupItem that is a subclass of Item that represents a Group)? Now your Group can include both images and groups -- so you can have subalbums, search results that can return folders or things like saved searches, etc. Even the gallery index can be subclass of Group (with the default view being root-level albums).
If you went that route (or even if you didn't), I'd also be very tempted to pass the URL processing to those classes -- let the URL determine the object the send the next part of the URL to. My experience so far, limited as it is, is that adding new classes means dealing with the URL handling (a la rewrite_get_album_image(), etc) a lot more than is fun. If the URL matches the object structure (and not the physical structure), then that should be a whole lot easier.
Member
Further thoughts... As for the database/filesystem duality, I think that if you want to embrace an object model something like the above, the major change will be switching (conceptually) zenphoto from a filesystem-based system with metadata stored in the DB, to an object based data store driven off the DB, some items of which have filesystem components as part of their make up.
Anywho, I'm curious to see what you plan to do going forward. I'm still trying to decide if I next want to tackle creating a new type of image class in the existing framework, or if I'd be better hacking up the existing one. The later option might be a lot easier on me, but much less useful for the community at large.
Anywho, I'm curious to see what you plan to do going forward. I'm still trying to decide if I next want to tackle creating a new type of image class in the existing framework, or if I'd be better hacking up the existing one. The later option might be a lot easier on me, but much less useful for the community at large.
Developer
Bingo, I like your thinking. The URLs are tied to the album/image structure as it is right now, and that'd have to go. In place would be some kind of table of mappings, with groups being able to define their own URLs.
This is good, very good. Let's call it 1.2, after I add subalbums support to the admin I'll dig right into this. Very very cool. If you want to start sooner than me, please do. You have exactly the right idea, I trust you'd implement it as well as you're conceptualizing it :-) Just make sure to keep me in the loop ;-)
Groups as items within groups is the next logical progression.. I had that in mind a while ago, just forgot to mention it here. The technical details shouldn't be too bad... just have to think through our representations and ideas clearly and make sure everything has an interface that makes sense and holds the class abstractions...
How bout we start a Wiki page? Let's continue discussion there and further refine the model...
http://www.zenphoto.org/trac/wiki/ZenphotoDevModel
This is good, very good. Let's call it 1.2, after I add subalbums support to the admin I'll dig right into this. Very very cool. If you want to start sooner than me, please do. You have exactly the right idea, I trust you'd implement it as well as you're conceptualizing it :-) Just make sure to keep me in the loop ;-)
Groups as items within groups is the next logical progression.. I had that in mind a while ago, just forgot to mention it here. The technical details shouldn't be too bad... just have to think through our representations and ideas clearly and make sure everything has an interface that makes sense and holds the class abstractions...
How bout we start a Wiki page? Let's continue discussion there and further refine the model...
http://www.zenphoto.org/trac/wiki/ZenphotoDevModel
Developer
Sorry-- didn't refresh the page while writing that and creating wiki page -- that was just in response to your first post.
Re: Further thoughts...
I agree somewhat. Still, I believe it's very valuable to be able to stick an image in a folder and not do [i]anything else[/i] and have it already be part of the gallery. That, in my opinion, shouldn't go away with any new database model.
But I think we could get the best of both worlds. I mean, if you're basing the gallery on the database, you [i]still[/i] have to find the images on disk at some point (whether through an import, or an add, or some kind of discovery), so there's no difference from what zenphoto already does. In fact I see a huge advantage to keeping that duality intact.
The big change we have to make is in keeping the database fresh and current, and I think that's not terribly hard to do. The other change is to make [i]some parts[/i] of the database [i]not[/i] mirrored on the filesystem (Tags, which have no filesystem equivalent, or SearchResults, which could be saved and used as a dynamic group of images, but still have no filesystem equivalent, Dynamic or Remote images that are loaded from URLs or other Zenphoto installations, which don't have a filesys equivalent (just came up with that one...)). So those would be maintained separate of the album/image/filesystem mentality, but [i]equally well and at no loss[/i]. As long as the database is kept up-to-date of the files on the filesystem, and does a few checks when an image is loaded then we shouldn't have a problem, and we get the best of both worlds.
Okay, on to the Wiki. I'll be copying our discussion there.
Re: Further thoughts...
I agree somewhat. Still, I believe it's very valuable to be able to stick an image in a folder and not do [i]anything else[/i] and have it already be part of the gallery. That, in my opinion, shouldn't go away with any new database model.
But I think we could get the best of both worlds. I mean, if you're basing the gallery on the database, you [i]still[/i] have to find the images on disk at some point (whether through an import, or an add, or some kind of discovery), so there's no difference from what zenphoto already does. In fact I see a huge advantage to keeping that duality intact.
The big change we have to make is in keeping the database fresh and current, and I think that's not terribly hard to do. The other change is to make [i]some parts[/i] of the database [i]not[/i] mirrored on the filesystem (Tags, which have no filesystem equivalent, or SearchResults, which could be saved and used as a dynamic group of images, but still have no filesystem equivalent, Dynamic or Remote images that are loaded from URLs or other Zenphoto installations, which don't have a filesys equivalent (just came up with that one...)). So those would be maintained separate of the album/image/filesystem mentality, but [i]equally well and at no loss[/i]. As long as the database is kept up-to-date of the files on the filesystem, and does a few checks when an image is loaded then we shouldn't have a problem, and we get the best of both worlds.
Okay, on to the Wiki. I'll be copying our discussion there.