- lovely.tag is a tagging system, which from my cursory look (at both packages) may be somewhat similar to tagger by Whit Morris of OpenPlans.
- lovely.ratings is a ratings system for content. Again, there seems to be some overlap with Alec Mitchell's contentratings package.
- lovely.remotetask is a framework for executing remote tasks, i.e. on a different host.
As we begin to realise the benefits of the Zope 3 re-use story, we need to be careful to examine what software already exists and how we may leverage it in Plone without having to re-invent too many wheels. Part of that may also be to look at how some of the existing packages that overlap could be consolidated, where this is practical.
5 comments:
Whit had already contacted us about the tagging engine. The big difference is that he works with RDF like structures (subject-verb-object relations) while we are working on a 2-part relationship. The reason we went this way is that we did not want to go down the route of making tags the ultimate way for specifying meta-data, since this is not very sensible. Also, we are providing grouping and other organizational features in a different package. The lovely.tag package is optimized for speed and simplicity.
As for content rating, Jodok did ask me to look at Alec's stuff before starting, but since I had already developed the schooltool.requirement, which has a very advanced scoring framework, I decided to go with that instead.
Overall, of course, the lovely packages are very light on UI and concentrate mainly on a robust API and scalable implementation.
We will also write eventually real REST-based Web services for them; but this has to wait a couple of months.
I had a quick peek at lovely.rating, and it looks great. My contentratings was just quickly thrown together for a client need, so I'm more than happy to abandon it for a cleaner solution. Stephan's implementation is a very nice improvement over it. I think Martin will be very happy with the multidimensional scoring system. We can easily make a little package that helps integrate this stuff in the plone ui/catalog (as contentratings does), and hopefully we can come up with some model for using local components to apply ratings to various content types TTW on a site by site basis. :-)
All greek to me... (long yawning)
Thank for the clarification guys :)
The most important thing, in my mind, i that we're talking to each other and aware of each other's work as far as possible.
sigh.
I have to disagree a bit with mr. richter's representation of the differences here. The relationships are essentially the same, the RDF is just the store vs. much like the ZODB is the storage for lovely.tag. Tagger is operating at essentially the same level as the class represented by taggingEngine in lovely.tag.
not sure what "we did not want to go down the route of making tags the ultimate way for specifying meta-data, since this is not very sensible" means.
If you have some design feedback, stepha n, feel free to send it to me. I'll try to address what I think you are saying here:
Conceptually, tags in tagger are treated as a form of annotations stored in RDF. The literal values of tags could be represented elsewhere as content or in some other store, but if represented inside the RDF store, it makes such things as translation and tag merging relatively easy. Through rdflib and SPARQL, we can query the store in an style similar to SQL. The main advantage of this approach come when a variety of RDF is cataloged in the rdfstore making more interesting queries possible.
For example, if you have a site taxonomy, Creative Common Licensing, FOAF and DOAP profiles along with user submitted annotations(tags, stickies, etc), you then can, a single call, do cross section queries for like the following: all in a section of hierarchy content with a certain license by a certain person with a certain tag.
pretty powerful.
I took a look under the hood at lovely.tag, and I think it would be too hard to actually use tagger as the TaggingEngine. Some minor refactoring to tagger's interfaces should make the two compatible. tagger uses a concept of context(multiple bounded sets in a Graph) whereas I guess lovely tag would deal with subsite scenarios by having multiple engines; `tagger` could work with this.
The APIs are pretty close so refactoring the integration stack wouldn't be too hard, though I have to look more.
Post a Comment